|
Mapping Roles to Groups and Users This article describes how Roles are mapped to Groups and Users in the Orion Application Server. 1 Introduction This article describes how Roles are mapped to Groups and Users in the Orion Application Server. 2 Overview Orion handles security identities through the notion of Groups and Users. A Group can consists of a number of Users. A J2EE application uses Roles to define access to resources within the application. These Roles are then mapped to the Groups and/or Users defined in the Orion Application Server. The J2EE specification defines Roles but do not define how these should be mapped to security identities in the Application Server. The notion of Groups and Users are therefore Orion specific, as is the procedure of adding Groups and Users as well as mapping Users to Groups. This article describes how to configure the mapping between Roles and Groups upon deploying an J2EE Application on the Orion Applicaton Server. 3 Default Behaviour The Orion default behaviour to handle mapping of Roles defined in a application.xml file (or the descriptor file of a stand-alone module such as web.xml) of an Application to Groups is to assume that the Role should be mapped to a Group with the same name as the Role . Thus, if the Application is using the name "users" for a Role , Orion would map this Role to the Group with the name "users" in a default installation, as the default installation has a global Group defined with the name "users" (as shown in listing 1 below).
4 Configuring Role-mappings Role-mappings are defined in the orion-application.xml file generated upon deploying an J2EE application on the Orion Application Server, or in the deployment configuration file of a J2EE module (such as a Web-module or EJB-module). The mapping is defined by using the "security-role-mapping" tag to wrap any number of "group" or "user" tags. This makes it possible to define that the Role "gatekeeper" should be mapped to the specific Users "Joe" and "Marry", or that it should be mapped to the Group named "gateAdministrators". Listing 2 below shows a simple Role-mapping definition where the Role "Admin" of an certain Application should be mapped to the Group "administrators".
The example in listing 2 above implies that there is a Group named "administrators" defined either in the applications local principals.xml file (located in the Applications deployment directory) or in the global one (normaly located in orion/config directory). Any tests that the Application performs on the Role "Admin" will be true for any Users that belongs to the Group named "administrators". Listing 3 below shows a simple Role-mapping definition where the Role "Admin" of an certain Application should be mapped to the Groups "administrators" and "superadmins", as well as the User "casper".
The example in listing 3 above implies that there are Groups named "administrators" and "superadmins" defined together with a User named "casper" either in the local principals.xml file (located in the Applications deployment directory) or a global one (normaly located in orion/config directory). Any tests that the Application performs on the Role "Admin" will be true for any Users that belongs to the Groups named "administrators" or "superadmins", as well for the specific User named "Casper". Listing 3 below shows a simple Role-mapping definition where the Role "User" of an certain Application should be mapped to all Users, by settin the value of the impliesAll to true.
Where the value of the impliesAll attribute is either "true" or "false", with "false" being the default. Any tests that the Application performs on the Role "Users" will be true for any User. Copyright © 2005 IronFlare AB |