EJB Security and J2SE Access Control

As an attentive reader, you must have noticed the semantic similarity between java policy files of JAAS and the portions a bean deployment descriptor that specify method level access control. The former grants certain permissions based on the identity of the current user, among other things, and is enforced by the security manager. The later specifies permission to invoke certain methods based on the identity of the current user and is enforced by the container. How are these two mechanisms different, besides the obvious difference in the syntax?

Let us understand this relationship by answering the following question.

Is the identity returned by getCallerPrinicpal() in a bean related to the Subject associated with the current Access Controller of the JVM? Recall that this Subject instance can be obtained by calling Subject.getSubject(AccessController.getContext()). Intuitively, one would assume that the value returned by the getCallerPrincipal() should be one of the principals of the Subject of the current Access Controller.

In reality, EJB2.0 specification doesn't mandate this behavior. An implementation is free to use either the JAAS-based access control or something else. In fact, WebLogic Server doesn't use JAAS for enforcing access control for EJBs. This, however, doesn't mean that the access control restrictions specified through policy files are not honored. So, in effect, one could use policy files to supplement EJB access control.

A new JSR, JSR-115: Java Authorization Contract for Containers, is standardizing how a container could use JAAS for access control decisions related to Web components and EJBs. One hopes that the future versions of J2EE App Servers will use JAAS for access control.