EJB.15.6 EJB Container Provider's ResponsibilitiesThis section describes the responsibilities of the EJB container and server provider. EJB.15.6.1 Deployment ToolsThe EJB container provider is responsible for providing the deployment tools that the deployer can use to perform the tasks defined in Section EJB.15.4. The deployment tools read the information from the deployment descriptor and present the information to the deployer. The tools guide the deployer through the deployment process, and present him or her with choices for mapping the security information in the deployment descriptor to the security management mechanisms and policies used in the target operational environment. The deployment tools' output is stored in an EJB container specific manner, and is available at runtime to the EJB container. EJB.15.6.2 Security Domain(s)The EJB container provides a security domain and one or more principal realms to the enterprise beans. The EJB architecture does not specify how an EJB server should implement a security domain, and does not define the scope of a security domain. A security domain can be implemented, managed, and administered by the EJB server. For example, the EJB server may store X509 certificates or it might use an external security provider such as Kerberos. The EJB specification does not define the scope of the security domain. For example, the scope may be defined by the boundaries of the application, EJB server, operating system, network, or enterprise. The EJB server can, but is not required to, provide support for multiple security domains and/or multiple principal realms. The case of multiple domains on the same EJB server can happen when a large server is used for application hosting. Each hosted application can have its own security domain to ensure security and management isolation between applications owned by multiple organizations. EJB.15.6.3 Security MechanismsThe EJB container provider must provide the security mechanisms necessary to enforce the security policies set by the deployer. The EJB specification does not specify the exact mechanisms that must be implemented and supported by the EJB server. The typical security functions provided by the EJB server include:
EJB.15.6.4 Passing Principals on EJB Architecture CallsThe EJB container provider is responsible for providing the deployment tools that allow the deployer to configure the principal delegation for calls from one enterprise bean to another. The EJB container is responsible for performing the principal delegation as specified by the deployer. The minimal requirement is that the EJB container must be capable of allowing the deployer to specify that the caller principal is propagated on calls from one enterprise bean to another (i.e., the multiple beans in the call chain will see the same return value from getCallerPrincipal() ). This requirement is necessary for applications that need a consistent return value of getCallerPrincipal() across a chain of calls between enterprise beans. EJB.15.6.5 Security Methods in javax.ejbEJBContextThe EJB container must provide access to the caller's security context information from the enterprise beans' instances via the getCallerPrincipal() and isCallerInRole(String roleName) methods. The EJB container must provide this context information during the execution of a business method invoked via the enterprise bean's remote or home interface, as defined in Table EJB.6-1 on page 406, Table EJB.6-2 on page 417, and Table EJB.9-1 on page 459. The container must ensure that all enterprise bean method invocations received through the home and remote interfaces are associated with some principal. The container must never return a null from the getCallerPrincipal() method. EJB.15.6.6 Secure Access to Resource ManagersThe EJB container provider is responsible for providing secure access to resource managers as described in Section EJB.14.4.3. EJB.15.6.7 Principal MappingIf the application requires that its clients are deployed in a different security domain, or if multiple applications deployed across multiple security domains need to interoperate , the EJB container provider is responsible for the mechanism and tools that allow mapping of principals. The tools are used by the system administrator to configure the security for the application's environment. EJB.15.6.8 System PrincipalThe EJB 1.1 specification does not define the "system" principal under which the JVM running an enterprise bean's method executes. Leaving the principal undefined makes it easier for the EJB container vendors to provide the runtime support for EJB architecture on top of their existing server infrastructures . For example, while one EJB container implementation can execute all instances of all enterprise beans in a single JVM, another implementation can use a separate JVM per EJB JAR per client. Some EJB containers may make the system principal the same as the application-level principal; others may use different principals, potentially from different principal realms and even security domains. EJB.15.6.9 Runtime Security EnforcementThe EJB container is responsible for enforcing the security policies defined by the deployer. The implementation of the enforcement mechanism is EJB container implementation specific. The EJB container may, but does not have to, use the Java programming language security as the enforcement mechanism. For example, to isolate multiple executing enterprise bean instances, the EJB container can load the multiple instances into the same Java virtual machine and isolate them via using multiple class-loaders, or it can load each instance into its own Java virtual machine and rely on the address space protection provided by the operation system. The general security enforcement requirements for the EJB container follow:
EJB.15.6.10 Audit TrailThe EJB container may provide a security audit trail mechanism. A security audit trail mechanism typically logs all java.security.Exception s. It also logs all denials of access to EJB servers, EJB container, EJB remote interfaces, and EJB home interfaces. |