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.