Summary

EJB defines the component architecture for Java-based distributed applications. This architecture is based on the premise that the components, or beans, should concern themselves with business logic and leave system-level issues of scalability, security, high availability, transactions, and so on. to be addressed by a bean container. Another noteworthy aspect of this architecture is the separation of responsibilities among different roles involved in developing beans, assembling applications, deploying and administering them.

Confidentiality and integrity of messages exchanged between an EJB and its client are ensured through SSL. A J2EE1.3-compliant product must support EJB invocation over SSL. The choice to use SSL is typically made by a client and can be controlled through the configuration. As we know, SSL offers not only confidentiality and integrity of messages but also the ability for the client to authenticate the EJB Server and for the EJB Server to authenticate the client.

In the EJB architecture, most of the security-related decisions are specified in deployment descriptor files declaratively. This allows a majority of security policies to be specified without modifying bean source code, or even having access to it. For a minority of cases where authorization decisions must be made within the bean code, it can determine the caller identity and check whether the caller has been assigned a particular role or not.

Part of the deployment descriptor structure is specified in the EJB specification and part is container implementation dependent. This split allows App Server vendors to optimize things during deployment and administration as per their implementation without compromising portability of beans and assembled applications.

A Java client program authenticates a user to EJB Server either by supplying the user credentials through JNDI or by authenticating the user at the client itself through JAAS. Though the basic mechanisms are outlined in the EJB and related specifications, a lot of details are usually implementation dependent.

Within a protection domain, user identities can be propagated or delegated without transferring user credentials. This allows a Web component, such as a servlet, to map a potentially large number of users to relatively few users of an EJB or a backend enterprise information system, without storing plain-text passwords for these users.