5.6 Security Considerations

< Day Day Up >

5.6 Security Considerations Although not specifically a security consideration, the EJB programming model constrains an enterprise bean to a limited set of resources. Specifically, in a J2SE environment, an enterprise bean is prohibited from using many Java resources as a result of EJB's isolation architecture. This architecture scales well in a multiprocess and multithreaded WAS environment. Each enterprise bean needs to be designed to run by itself and not interfere with other enterprise beans. For example, enterprise beans must not include native method calls, as native code could adversely affect other enterprise beans, as well as be nonportable. This also means that enterprise beans must not write to static fields or attempt to share state with other enterprise beans except via remote method calls or via resource managers, such as JDBC and JMS. Note that because the EJB container is middleware and acts as a broker, it can make native calls and use restricted Java resources. Given the isolation architecture of EJB components, each enterprise bean needs to interact with other enterprise beans via remote method calls. As the interaction will be location independent and may cross machine boundaries, it is important to define and enforce a secure association mechanism between EJB components. The channel of communication should provide data confidentiality and integrity. Using SSL communication between the EJB containers may address these requirements. It is also important for the security context associated with the client enterprise bean to be passed on to the target enterprise bean so that the identity of the client gets propagated through the invocation. A mechanism that achieves secure association between the client and the target EJB components needs to address the quality-of-service requirements.

< Day Day Up >