Enterprise Security with EJBs

  

As you know, J2EE Enterprise JavaBeans are server-side components that provide a model to simplify the development of transactional, scalable, and portable middleware. EJB servers provide automatic support services such as transactions, security, database connectivity, and more. EJBs encapsulate business logic and provide services to clients . A good resource for EJB information and J2EE in general is Sun's BluePrints site at http://java.sun.com/blueprints/index.html .

The EJB architecture defines components, servers, containers, and clients. It is the EJB container that provides life-cycle management for the enterprise beans and provides services - by intercepting calls from the client. Examples of these services are security, concurrency control, and transactional services, which are provided to the client, however the client is not aware of the container. The EJB container resides in the EJB server that provides services such as directory, naming, and e-mail services.

The home interface provides the methods to create, remove, and get metadata for the EJBs. This interface extends javax.EJB.EJBHome .

The remote interface defines the client view set of business methods. It must extend javax.ejb.EJBObject, which defines the methods for clients to obtain the home interface, remove an EJB instance, and obtain a handle to the EJB instance, among other things.

The enterprise bean class provides the actual implementation of the business methods of the bean. It must implement the javax.ejb.EntityBean or javax.ejb.SessionBean interface. It also implements a corresponding ejbCreate method for each create method in the home interface. In addition, for each finder method in the home interface, the enterprise bean class implements corresponding ejbFindBy methods.

The behavior of an EJB is defined partly in the implementation and customized at deployment time via a deployment descriptor.

Understanding EJB components

There are three major types of EJBs: session , entity, and message driven beans . The specification defines the life cycle for each type of bean. This section describes each EJB type and its life cycle at a high level, skipping many of the details.

Session beans

Session beans model processes, services, and client sessions. They are used as resources only by the client that created them. There are two types of session beans: stateless and stateful. Stateless beans do not keep the session data information, also called the conversational state , between calls from the client. This type of bean does not survive server crashes since it does not keep its state.

The life cycle of a stateless session bean starts in the does not exist state, which means the instance has not been instantiated . The container creates a new instance via the newInstance method and it then calls the setEntityContext method. The stateless bean then enters the pooled state where it is ready to provide services (via calls to the exposed business methods). When the container no longer requires the instance, it calls the ejbRemove method.

Note  

A member variable is part of the conversational state if it is a non-transient primitive type or a non-transient Java object.

Stateful session beans keep the state within the bean. That is, the state is kept across multiple methods as well as different invocations of the same method from the client. This works because the client establishes a conversation with the bean. The bean is required to remember the state of the conversation in subsequent calls. Therefore, if the container needs to put the bean in the pool, the bean is passivated . A bean is passivated when its conversational state is saved to persistent storage such as the hard disk.

Passivation is required because the state must be available when the client requires a service and a bean instance is required from the pool to service it. The process of retrieving the state from persistent storage is called activation . Activation allows the bean instance to have the same conversational state to service the client request, however the bean instance may not be the same as the previous instance before passivation. This process is transparent to the client.

The stateful session bean has four states: the "does not exist," the "non-transaction method-ready," the "transaction method-ready," and the passive state. As with the stateless session bean, the does not exist state means that the bean has not been instantiated. The client calls the create method on the home interface and the container calls the newInstance , the setSession, and the ejbCreate methods.

At the time of deployment, you specify whether the bean is part of a transaction, and if so, the transaction method-ready state is where the business methods are serviced. In this state the bean cannot be passivated and the bean transitions to the non-transaction method-ready state if there is a commit or a roll back of the transaction. The bean enters the passive state if it has been passivated - from the non-transaction method-ready state and transitions back to it via an ejbActivate method call. Non-transactional business methods are serviced in the non-transaction method-ready state. The bean goes back to the does not exist state after an ejbRemove method call (from the non-transaction method-ready state) or after a time out (from the passive state).

Entity beans

Entity beans provide a view of persisted data, such as records in a database, and they model real-world objects such as customers and projects. Entity beans instances are created and managed by the EJB container . When the client calls create , the container creates the instance and calls setEntityContext of the entity bean class, which passes the entity context to the bean. The next step in the entity bean's life cycle is the pooled state.

The EJB specification describes an architecture in which the container keeps a free pool of entity bean instances and moves them in and out of this state. In the pooled state, all beans are the same and are not associated to an EJB object. From the pooled state, the entity bean moves to the ready state. In the ready state, the EJB is associated with an object.

There are two ways in which the entity bean is moved to the ready state: Either the container activates it (via the ejbActivate method) or the client calls the create method. If the create method is called, the ejbCreate and ejbPostCreate methods are invoked by the container; it is in these methods that you perform any necessary logic. When the client calls the remove method, the container invokes the ejbRemove method and the entity bean is moved to the pooled state. Another way for the entity bean to go to the pooled state is for the container to invoke the ejbPassivate method. Finally, the EJB container removes the instance from the pool and invokes the unsetEntityContext method.

Message driven beans

Message driven beans (MDBs) allow clients to asynchronously invoke server-side business logic. They are (as of this writing) JMS message consumers, but in the future they may be used to process other types of messages. MDBs work with queues and both durable and non-durable topic subscriptions. To create a new instance, the container instantiates the bean and calls the setMessageDrivenContext method.

At this point the instance is in the ready state to process messages. Invocations of the onMessage method are serviced in the ready state. These beans are stateless, so any instance may service any message and an instance may service multiple clients as well. The container may pool MDBs and assign any message to any MDB instance. Finally, the ejbRemove method is invoked when the bean goes back to the does not exist state.

Using authentication in J2EE components

As described in previous chapters, authentication is the mechanism by which an entity (a user or service provider) establishes its identity. That is, it proves that it is acting on the user or system's behalf . So, if the entity establishes the communication without authorization, it is an unauthenticated user.

Authentication is required when crossing the boundaries of protection domains. A protection domain is a set of entities that trust each other, and so these entities communicate without requiring authentication. You can think of the EJB container as a protection domain because it provides authentication boundaries between its components and their callers . However, container implementations may choose to host components of different protection domains.

There are two main forms of authentication that J2EE components use. The first is called container-managed resource manager signon . The other is called application-managed resource manager signon . As their names suggest, the main difference is whether the container or the application manages the resource access. For instance, in the container-managed resource manager signon case, because components may try to access resources in different protection domains, the calling container is configured to manage the authentication to those resources. In the application-managed resource manager signon , it is the application that manages the specification of the caller's identity for resource access.

Tip  

If you need to develop your own application-managed resource manager signon, use the connector architecture for portability.

As you probably know, each resource and J2EE component accessed by a component is declared in the deployment descriptor via elements. For instance, the resource-ref element declares the resources used by the component, and a re-auth element is used to declare the type of authentication required. Components can use can use the EJBContext.getCallerPrincipal and HttpServletRequest.getUserPrincipal methods to obtain the identity of their caller. The component may map the caller identity to a new identity and/or authentication secret as required by the target enterprise information system.

The authentication context encapsulates the identity. Access to the authentication context can be given in many possible ways through policies and mechanisms such as

  • to any process the user starts by allowing him access to the authentication context - once the user is authenticated.

  • once a component is authenticated, access to the authentication context may be made available to trusted components.

  • by delegation: the caller may delegate the authetication context to the called component.

Using authorization in J2EE components

Recall from previous chapters that an entity may need to be authorized to access a protected resource. For example, a user may be authenticated to use your application but may not be authorized to read certain files that the application may encounter (accounting files, for instance). Authorization is used to restrict access to resources based on constraints. The identity of the caller is available in the authentication context and may be propagated. In addition, it may be an anonymous call where the identity of the caller is not provided.

Similar to the container providing a protection domain for its components, it provides a boundary for authorization as well. The authorization boundary, however, may restrict entities' access to a resource even if they are within the same protection domain.

There are two models for authorization: declarative and programmatic authorization. Declarative authorization makes use of the deployment descriptor where security roles and their associations are specified. The EJB container grants access to methods based on these associations. This gives flexibility after the application has been written; all you need to do is modify the deployment descriptor to change the security.

Programmatic authorization provides finer-grain control over privilege and security roles. In the deployment descriptor the element security-role-ref is used to link a privilege name to a security role. A component can call the EJBContext.isCallerInRole or isUserInRole to check whether the caller has been granted the correct privilege to access the requested resource and proceed if the proper rights are encountered .

Note  

Recall that authorization can be programmatic or declarative. Programmatic authorization is embedded in code and the developer controls (and checks) whether the user is authorized to access the resource or operation. In declarative authorization, the access rules are described in the deployment descriptor and the EJB container is responsible for controlling the access to the operation or resource.

Configuring EJB component security

The deployer is responsible for configuring the container to provide the security and other necessary services. The deployer configures the container for the functionality that it needs to provide services such as message integrity, message encryption, and auditing.

For message integrity the container computes and attaches a message signature to the request. The target container verifies the signature of the request and attaches a message signature to the response. The communication fails if the verification fails. Because there is performance overhead, you may want to specify which messages require integrity and specify them through the deployment description.

The deployer configures the container for message encryption when the communication between its components and their clients requires confidentiality. Again, there is a performance hit and only those methods that require confidentiality should be identified as such at deployment time. Also, the container needs to be configured to reject any communication that requires confidentiality and is not protected.

Auditing is important, especially when security has been breached, because it allows you to see not only who has been denied access but also who has been given access to the system. The deployer is responsible for the configuration of the EJB container. These constraints should be analyzed and associated with an audit if necessary.

As described, the deployment descriptor, via elements, specifies the access rights (among other things) to resources and components. For example:

  • The method-permission element in the deployment descriptor is used to specify access rights to the methods of the remote and home interfaces for Enterprise JavaBeans. You can give unrestricted access to a resource or method by mapping a role to all the users and giving the role access to the resource. In addition, the description subelement (of the method-permission element) is used to identify whether the method needs integrity or confidentiality or both.

  • The element resource-ref is used to declare the resources used by a component. If the resources contain sensitive information, they are described in the description subelement (of the resource-ref element).

  • The security-role-ref element is used to specify the link between a privilege name and a security role.

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

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