EJB.15.6 EJB Container Provider s Responsibilities


EJB.15.6 EJB Container Provider's Responsibilities

This section describes the responsibilities of the EJB container and server provider.

EJB.15.6.1 Deployment Tools

The 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 Mechanisms

The 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:

  • Authentication of principals.

  • Access authorization for EJB calls and resource manager access.

  • Secure communication with remote clients (privacy, integrity, etc.).

EJB.15.6.4 Passing Principals on EJB Architecture Calls

The 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.ejbEJBContext

The 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 Managers

The 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 Mapping

If 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 Principal

The 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 Enforcement

The 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:

  • The EJB container must provide enforcement of the client access control per the policy defined by the deployer. A caller is allowed to invoke a method if, and only if, the caller principal is assigned at least one of the security roles that includes the method in its method permissions definition. (That is, it is not meant that the caller must be assigned all the roles associated with the method.) If the container denies a client access to a business method, the container must throw the java.rmi.RemoteExcetion to the client.

  • The EJB container must isolate an enterprise bean instance from other instances and other application components running on the server. The EJB container must ensure that other enterprise bean instances and other application components are allowed to access an enterprise bean only via the enterprise bean's remote and home interfaces.

  • The EJB container must isolate an enterprise bean instance at runtime such that the instance does not gain unauthorized access to privileged system information. Such information includes the internal implementation classes of the container, the various runtime state and context maintained by the container, object references of other enterprise bean instances, or resource managers used by other enterprise bean instances. The EJB container must ensure that the interactions between the enterprise beans and the container are only through the EJB architected interfaces.

  • The EJB container must ensure the security of the persistent state of the enterprise beans.

  • The EJB container must manage the mapping of principals on calls to other enterprise beans or on access to resource managers according to the security policy defined by the deployer.

  • The container must allow the same enterprise bean to be deployed independently multiple times, each time with a different security policy. [2] The container must allow multiple-deployed enterprise beans to coexist at runtime.

    [2] The enterprise bean is installed each time using a different JNDI name .

EJB.15.6.10 Audit Trail

The 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.



Java 2 Platform, Enterprise Edition. Platform and Component Specifications
Java 2 Platform, Enterprise Edition: Platform and Component Specifications
ISBN: 0201704560
EAN: 2147483647
Year: 2000
Pages: 399

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net