Propagation of Security Principals to Other Containers on the J2EE Engine 

J2EE Web applications comprise the highest level of an enterprise J2EE application. As such, they are usually the entry point to all other components from the business logic layer of the application. Therefore, authentication of users takes place within the Web Container.

Propagation of Security Principals

Consequently, if the requested Web application resource must use another security-sensitive resource that is managed by another container on the J2EE Engine (such as a Web Services container, or an EJB container) to serve the client request, the Web Container must propagate the caller’s identity to the corresponding container. The responsible container checks the caller identity’s security principals against the security configurations the called resource is deployed with, and either grants or denies access to it. The user permissions are determined based on association with a configured security role.

Enterprise beans on the J2EE Engine use the standard J2EE API to handle the propagated caller identity and check its security role membership (that is the isCallerInRole() and getCallerPrincipal() methods of the EJBContext class). For Web services, this function is built in a security protocol that is registered with the Web Services Container service on the J2EE Engine.

Unauthenticated Users

Since it is possible that users can access unprotected Web application resources (that is, they are not authenticated), the Web Container must use pre-configured identities to propagate to other containers. The default account is the user Guest.

You can also use the standard J2EE run-as mechanism to configure the same. That is, using the web.xml deployment descriptor you can configure the run-as identity of your servlet or JSP, and it will be propagated when the call traverses the boundaries of the Web Container. For more information about configuring the run-as identity of a servlet or JSP, see Declaring and Configuring Web Components.

You configure the run-as identity on the J2EE Engine by mapping it directly to a security role as described in Declaring and Configuring Web Components. However, the run-as identity must propagate a single user’s identity to the other containers affected by the call of the unauthorized user. To address this issue, the Security Provider Service sorts the users that are associated to this role and selects the first one that is to be used as the run-as identity. We recommend that you have exactly one user associated to the role you map the run-as identity to, so that you always know that this user is propagated to other components involved (though you may have several other groups of users associated with that role at the same time).