EJB specifies declarative attributes for security authorization. Once a user has been authenticated (logged in), access to enterprise beans can be monitored and controlled. The declarative authorization attributes allow the container to control which users can access which methods on specific bean types. In EJB 1.0, individual methods on a bean are associated with Identity objects that represent individual users or groups of users called roles. Only users that are associated with the correct Identity objects can access the bean's methods. Using this approach, bean methods can be mapped to a set of identities in the serializable deployment descriptor.
When a bean method is invoked at runtime, the container examines the Identity of the caller and compares it to the list of Identity objects associated with that method. If the caller's identity matches or is a member of one of the identities associated with the method, the method can be invoked. Although this authentication model works well--it allows fine-grained functional authentication without requiring any code in the bean itself--it also has some problems. In an operational environment that supports ACL-based security, all the identities and roles in an enterprise are part of the operational environment. To choose Identity objects to associate with bean methods, you must have access to the ACL repository of the environment that the bean will be deployed in. For this reason, it is normally assumed that the deployer in EJB 1.0 will map the bean's methods to the security domain. Unfortunately, the deployer may not have a good understanding of the purpose and function of the bean methods. This makes it difficult for the deployer to determine what identities and roles should be mapped to which methods--a problem that is compounded in beans that have numerous methods.
In recognition of the authentication problems in EJB 1.0, EJB 1.1 has changed authentication security significantly. In EJB 1.1, the authentication service remains implicit and fine-grained, but it's permission driven rather than method driven. In EJB 1.1, the bean provider and the application assembler (the same person in many cases) defines logical roles in the XML deployment descriptor. One or more roles can be associated with a list of methods they have permission (authorization) to access. The roles are logical and have only semantic meaning. They are not obtained from a specific operational environment; they simply describe the type of user who can access a set of methods. The bean developer can provide additional information about the logical roles by attaching description tags to roles with comments.
The bean deployer, who works in the operational environment, maps the logical roles defined by the bean developer and application assembler to real roles in the environment's security system. In this way, the bean developer and application assembler can define the type of roles that have access to methods without having to know anything about the operational environment in which the bean will be deployed. Similarly, the bean deployer can map roles in the operational environment to the logical roles in the deployment descriptor, based on semantic meaning of the logical roles and their attached descriptions, without having to understand the purpose or function of the methods involved. In fact, the deployer need not be concerned with the methods at all since she is only concerned with roles and the methods with which they are associated.
 |  |  |
| D.4. The Default JNDI Context |  | D.6. Looking Ahead to EJB 2.0 |
Copyright © 2001 O'Reilly & Associates. All rights reserved.