Chapter 10. EJB Security
EJBs (Enterprise JavaBeans) define the component-based application architecture for distributed, enterprise-grade Java applications. Within this architecture, the components themselves are also known as EJBs, or just beans. An important aspect of this architecture is that it incorporates separation of system-level concerns such as multi-threading, resource pooling, persistence, transactions, security, management, and so on. from application specific functionality, as the basic design principle. Specialized software programs, known as EJB containers, host EJBs and provide the above-mentioned system-level capabilities as per the EJB specification. Individual EJBs implement business functionality, adhering to the container contract.
An EJB container is usually part of a J2EE Server. A J2EE App Server supports other containers like a Web container and provides a variety of services to programs deployed on these containers as per J2EE specification.
In many ways, EJBs are like RMI server classes exposing their functionality to remote clients through remote interfaces. After all, the primary objectives of both EJBs and RMI servers are quite similar—development of distributed applications. As we have seen in the chapter RMI Security, RMI offers basic capabilities of network-level connection management, marshalling and unmarshalling of Java objects, discovery through RMI Registry and exception-based error handling. EJB architecture makes use of these RMI capabilities as underlying infrastructure and adds the advanced system-level capabilities mentioned above, including a comprehensive security model.
Besides addressing system-level issues for enterprise applications, EJBs are also architected to promote reuse of business components across multiple applications and provide flexibility in their deployment and administration as per the needs of the enterprise. This is accomplished through clear separation of concerns and specification of clear contracts among different roles performing different functions: Bean Providers are domain experts who develop EJB code, Application Assemblers assemble EJBs from different sources to create an application, Application Deployers deploy the assembled application to the production environment, and System Administrators look after day-to-day functioning of the application. It is important to keep in mind that these roles are defined with clear assignment of responsibilities for the purpose of achieving conceptual clarity only, and in practice, one person or a group can perform the functions of multiple roles. Especially during development of a self-contained small application, it is common for one person, the developer, to perform the functions attributed to all the roles.
These different roles and their responsibilities provide guidelines for incorporating appropriate security constructs in different part of an EJB-based application. As we see later, different roles make different security decisions and the sum total of these decisions defines the overall security. At times, especially during development when the developer plays all the roles, some of the abstractions might seem redundant and a source of needless complexity. However, as the system grows in size and functionality, and the different functions get divided among different groups, these abstractions become more and more relevant.
Although EJB specification standardizes a good many security features, there are details that depend on the specific App Server implementation. If you recall, this is the same observation we made with respect to Web containers while going over how Apache Tomcat associates a user account system with a particular Web application. Configuration-related details and administrative tools are usually not part of the standard and must be done in a product-specific manner.
In practical terms, what it means is that we need to choose a particular App Server for illustrating examples, the same way we chose Apache Tomcat as the server for the Web container, knowing fully well that some of the steps may not work for other implementations. However, the selection of Apache Tomcat was a no-brainer—it is the RI (Reference Implementation) for Servlet and JSP specification and is also open source. No such luck with the EJB container. Though there exists an open source, and popular in certain segments, App Server implementation, the JBoss Application Server (http://www.jboss.org), but its J2EE-compliance is not certified. The J2EE certification status may not matter to a real deployment but it does matter to a book that is written to explain the features specified in the J2EE standard.
After considering a few J2EE App Servers, I chose BEA WebLogic Server 7.0 SP2, a commercial, J2EE1.3-certified App Server. This choice was influenced by my own familiarity with this product and the availability of a large number of ready-to-build-and-run example programs as part of the download. As an added attraction, a limited time, free evaluation license is available to all developers.
Before we dive into EJB security mechanisms, let us go through an overview of the EJB technology and get familiar with the BEA WebLogic Server 7.0. We do so by writing a simple EJB application and deploying it within the WebLogic Server.