15.3 Authorization

< Day Day Up >

15.3 Authorization Authorization in a J2EE environment is based on the concept of roles. A user who has been granted at least one of the required roles is allowed to access a resource, such as a method in an enterprise bean. In the J2EE deployment descriptor, role names are associated with a set of method permissions and security constraints. The containers are responsible for mapping users and groups to these roles so that an authorization decision can be made when a resource is accessed. There are at least two ways to implement a role-based authorization engine: the role-permission model and the role-privilege model. The role-permission interpretation of the J2EE security model considers a role to be a set of permissions and uses the role name defined in the method-permission and security-constraint descriptors as the label to a set of permissions. A permission defines a resource�the enterprise bean to which a method-permission descriptor applies or a URI described in a security-constraint descriptor�and a set of actions�remote EJB methods or HTTP methods. For example, a Teller role may be associated with a set of permissions to invoke the getBalance() method on an AccountBean enterprise bean and to perform a GET invocation over HTTP to a /finance/account URI. If multiple method-permission descriptors refer to the same role, they are consolidated so that a single set of permissions is associated with the role name, likely within the scope of that application. Administrators define authorization policies for the roles in their application. This is done by associating subjects to a role, an operation that grants each subject the permissions associated with that role. This effectively grants the subject access to the enterprise bean methods and to the URIs permitted by that role. The method-permission table represents the association of a role to a set of permissions (see Table 3.1 on page 84). Based on the J2EE security model, a method can be accessed by a user who has at least one of the roles associated with the method. The roles associated with a method form the set of required roles to perform an action. The roles associated with a subject form the set of granted roles to that subject. A subject will be allowed to perform an action if the subject's granted roles contain at least one of the required roles to perform that action. An authorization table, or protection matrix, represents the association of a role to subjects (see Table 3.2 on page 84). In such a table, the role is defined as the security object, and users and groups are defined as security subjects. According to the J2EE security model, it is responsibility of the Application Assembler to associate actions on protected resources to sets of required roles. The Deployer refines and configures the policies specified by the Application Assembler when the application is installed into a WAS. Association of roles to subjects can be performed when the application gets installed in a WAS or at a later time, as part of security administration. An alternative approach to implement role-based authorization is to treat a role as a privilege attribute, typically a user group. For example, if a role name is Manager, a user group named Manager should be defined in the user registry. This model has advantages and disadvantages. This approach has the advantage of maintaining only one table�the method-permission table�because the subject who is assigned a role is implicitly a user group that has the identical name. In the example given in Table 3.1 on page 84, user groups with the names Teller and Supervisor will be defined in the user registry. This approach has the disadvantage that for every role defined in an application, a user group needs to be defined in the system. If two applications use the same role name, care should be taken to ensure that the users who are members of a user group identical to the defined role names are allowed to access both applications. Additionally, in order to manage users and groups in a user registry and associate them at will with user groups named identical to roles, the user registry would need to support nested groups. For example, if the Supervisor role should be assigned to the HRManagers user group, the HRManagers user group should be a subgroup of the Supervisor user group. This may be difficult to achieve in practice because not every user registry supports nested groups. Thus, unlike the role-permission model, the role-privilege model imposes a structure on the underlying user registry. Regardless of which model is used to achieve role-based authorization, the container runtime will need to make runtime authorization decisions each time an attempt is made to access a resource. For example, when the getBalance() method in the AccountBean enterprise bean is invoked, the container must make an authorization decision to verify whether the invocation is allowed. As the J2SE permission security model (see Chapter 8 on page 253) augmented by JAAS (see Chapter 9 on page 289) is rich enough to check permissions based on a subject, it is logical to use the J2SE permission model to perform access checks. Therefore, containers can invoke the java.lang.SecurityManager's checkPermission() method. This also implies that J2EE resources and methods will need to be modeled by different permission types. In Java 2, permissions are implemented as java.security.Permission objects (see Section 8.2 on page 258). The process of authorization starts from the time of application installation. When an application is installed, the deployment descriptor information that is stored with the application is read by the container deployment tools. The subject-to-role mapping is effectively managed using the tools provided by the container and/or security provider. Such tools must allow changing the permission-to-role mapping. Effectively, a set of policy management tools will help manage the security policies associated with authorization to access the various J2EE components. When a resource is accessed, the container will consult the authorization runtime provided by the security provider to verify whether the user accessing a resource can be allowed to perform the operation. The security provider may be the same vendor as the container provider or a different one. These steps are illustrated in Figure 15.3. Figure 15.3. Authorization in a J2EE Container The advantage of using the J2SE/JAAS Permission model is that a single security provider can perform both J2SE permission checks�for example, for accesses to the file system�and J2EE permission checks�for example, to execute EJB methods. Part of the design of authorization engines is to create java.security.Policy objects. Similar to how LoginModules can be used as an approach to allow multiple authentication mechanisms to be used by a container, one of many Policy implementations can be used by the container when making an access check on a resource.

< Day Day Up >