EJB Tier or Business Component Security

In a J2EE environment, the EJB tier represents the business components. It generally resides between the Web-tier or application-client components and the underlying database or EIS-tier components. The EJB tier typically consists of Session Beans, Entity Beans, and Message-driven Beans, along with associated helper classes. Each bean is typically packaged and deployed as a single component (.jar) file. A J2EE application can also be packaged to include multiple EJB components, Web components, and other resources as a J2EE application (.ear) file, along with an XML-based deployment descriptor file that contains the configuration information of the EJB component or J2EE application.

The EJB security model is a subset of J2EE security and follows security strategies that are similar to those applied to other J2EE components. While similar to Web components in terms of authentication and authorization models, the EJB specifications do not specify any supported authentication schemes and leave the responsibility of providing them to the J2EE vendor. EJB security options are more focused on authorization and access control. In a J2EE server, the EJB container implements the security services for the deployed EJB components. The security policies specified for the EJB components are enforced by the EJB container. Like Web components, the security policies of EJB components are expressed in terms of roles and permissions for accessible EJB methods. During runtime, when a client session makes an EJB invocation, the EJB container verifies the caller and determines its required method invocations. This is done by verification of whether the caller principal is mapped to a security role that is granted to execute specific methods.

The J2EE server allows us to protect the EJB-tier components and associated resources, adopting declarative or programmatic security.

EJB Declarative Authorization

With EJB declarative security, also referred to as declarative authorization, the EJB deployer defines the access control rules and policies externally, using a deployment descriptor, and then associates them with an EJB component. In practice, declarative authorization allows declaring security roles and then associating them with EJB method permissions. The EJB container takes responsibility for granting permissions to access bean methods for callers representing the defined security role and at least possessing one of the privileges associated with the bean method. The EJB deployer is responsible for mapping a list of roles to caller identities (principals) via J2EE vendor-specific descriptor mechanisms. Thus, defining a security policy declaratively for an EJB refers to defining which methods can be executed by which roles.

In an EJB deployment, the EJB deployment descriptor represents security roles and associated method permissions. The deployment descriptor can contain zero or more <method-permission> elements defined within an <assembly-descriptor> element to provide role-to-method access control mappings. A <method-permission> element can contain one or more <role-name> elements, and one or more <method> elements. The <role-name> elements contain the role name values that have been defined in a <role-name> element contained within the <security-role> elements. The <method> element identifies the EJB method(s) for which it is necessary to define access control permissions. Example 5-26 shows two method permissions: the first <method-permission> represents all the methods of the bean interfaces (including remote, home, local, and local home). The second <method-permission> applies to the specified <security-role>.

Example 5-26. Declaring role and associated method permissions

<ejb-jar> . . .  <assembly-descriptor> .. . <security-role>admin</security-role>     <method-permission>         <role-name>*</role-name>         <method>           <ejb-name>CSPSecureService</ejb-name>           <method-name>create</method-name>         </method>   </method-permission>   <method-permission>         <role-name>admin</role-name>         <method>           <ejb-name>CSPSecureService</ejb-name>           <method-name>adminService</method-name>         </method>   </method-permission>          ... </assembly-descriptor> . . . </ejb-jar> 

In addition to the <role-name> element, a <role-link> element can be defined within a <security-role-ref> element. Like Web components, this element value can be defined to establish EJB relationships using role names from one EJB to another.

There may be cases where you need to restrict a client from executing a list of methods of an EJB. In such cases, you can indicate the methods that should not be invoked using the <exclude-list> element. The methods listed under the <exclude-list> element are not callableregardless of the role, and in cases where a method is specified in both <exclude-list> as well as <method-permission> elements. Example 5-27 shows two methods that cannot be called because they are specified within an <exclude-list>.

Example 5-27. Declaring exclude lists for restricting EJB methods

<ejb-jar> . . .  <assembly-descriptor> .. .     <exclude-list>         <method>         <ejb-name>OldPartsCatalog</ejb-name>         <method-name>checkModelNo</method-name>         </method>         <method>         <ejb-name>OldPriceList</ejb-name>         <method-name>checkLastPrice</method-name>         </method>   </exclude-list>           ... </assembly-descriptor> . . . </ejb-jar> 

EJB Programmatic Authorization

The EJB programmatic authorization allows dynamic invocation of business methods based on the remote caller's security role. The programmatic authorization mechanism allows performing fine-grained access control using dynamic access rules when declarative options are not sufficient for expressing the EJB component security requirements. In practice, the EJB component can use programmatic methods to determine whether a caller has been granted a privilege based on the parameters of the call, the internal state of the component, or other factors such as the time of the invocation.

In the EJB tier, the programmatic authorization can be accomplished using the following methods of the EJBContext interface:

• isCallerInRole(): This method determines whether the caller of the EJB belongs to the specified role. It returns true or false, indicating whether or not the user is included in the role. The code in Example 5-28 checks whether the bean caller belongs to role "admin."

  Example 5-28. Verifying an EJB caller's associated role

  Boolean privilegedCaller               = ejbContext.isCallerInRole("admin"); 

  
  

• getCallerPrincipal(): This method returns a java.security.Principal object that contains the name of the current authenticated user making the call. This method is used to verify the caller's identity; if the identity verified is equivalent to the caller's identity, then the container will allow the caller to proceed with the invocation. If the identity verified is not equivalent to the caller's identity, the container denies further interaction. The code in Example 5-29 shows how to obtain the caller identity in the EJB using the ejbContext.getCallerPrincipal().getName() method.

Example 5-29. Obtaining the EJB caller identity

  public String getCallerIdentity() {          return        ejbContext.getCallerPrincipal().getName(); } 

Anonymous or Unprotected EJB Resources

If the EJB caller need not be authenticated and access is allowed to anonymous callers, then it is categorized as an unprotected EJB method. In the EJB tier, unrestricted access can be provided to EJB methods by using an unchecked element in the method permissions. The snippet in Example 5-30 shows how to use the <unchecked> element.

Example 5-30. Unrestricting access to EJB methods

<method-permission>     <unchecked/>     <method>       <ejb-name>ProductCatalogue</ejb-name>         <method-name>listBeverages</method-name>     </method>     <method>     ... </method-permission> 

Principal Delegation in EJBs

In a chain of invocations between one EJB and another, it is very important that the principal identity of the EJB that initiated the call is propagated to the other EJBs in the chain. This means that the principal identity associated with the original EJB must remain constant in all EJB method invocations and across other EJB servers (see Figure 5-5).

Figure 5-5. Principal delegation in EJBs

In general, the client principal of an EJB method that is invoked is associated with that subsequent invocation across other EJBs. If the EJB component of the other container has to use the caller's identity from the originating EJB container, the <user-caller-identity> option has to be specified to instruct the container. If the EJB method makes a call to another EJB and its defined principal is not the original caller, then to delegate the principal, each EJB has to be assigned with a <run-as> role and principal.

To better understand identity propagation (see Figure 5-5), let's consider a scenario where a client principal identity roleA calls an EJB MyEJB1.methodA() as principal roleA in EJB Server A and then calls EJB MySecureEJB2.methodB() to EJB server B. If both MyEJB1 and MyEJB2 have their security identity set to the <user-caller-identity>, then both MyEJB1.methodA() and MyEJB2.methodB() will execute using caller's principal roleA as its identity. To support this scenario, the EJB deployment descriptor will look like Example 5-31.

Example 5-31. EJB principal delegation using <user-caller-identity>

<ejb-jar> <enterprise-beans>    <session>       <ejb-name>MyEJB1</ejb-name>       <home>com.csp.MyEJB1Home</home>       <remote> com.csp.MyEJB1</remote>       <ejb-class> com.csp.MyEJB1Bean</ejb-class>       <session-type>Stateful</session-type>      <transaction-type>Bean</transaction-type>       <security-identity>          <user-caller-identity></user-caller-identity>       </security-identity>    </session> </enterprise-beans> </ejb-jar> 

Run-As

To make the originating EJB call on other EJB components use a different principal identity, it is necessary to use the <run-as> identity option. If the <run-as> identity option is specified, the container establishes the identity of the bean using the specified role name and propagates the <run-as> principal identity when it calls on other EJBs as a whole, including all methods of the home and the remote interfaces. Example 5-32 illustrates <run-as> identity in the EJB deployment descriptor in order to execute MyEJB2 using "roleB."

Example 5-32. EJB deployment descriptor for run-as different principal

<ejb-jar> <enterprise-beans>    <session>       <ejb-name>MyEJB2</ejb-name>       <home>com.csp.MyEJB2Home</home>       <remote> com.csp.MyEJB2</remote>       <ejb-class> com.csp.MyEJB2Bean</ejb-class>       <session-type>Stateful</session-type>      <transaction-type>Bean</transaction-type>       <security-identity>          <run-as>roleB</run-as>       </security-identity>    </session> </enterprise-beans> </ejb-jar> 

Using <run-as> identity is very useful when the business functionality requires delegation of certain operations without transferring complete access privileges to the caller principal. An example for its use is when an EJB is required to run privileged administrative tasks that make use of methods from another administrative EJB. Assigning the EJB with <run-as> identity will enable use of the administrative EJB without compromising the security and access privileges.

Security Context Propagation from Web Tier to EJB Tier

In a J2EE environment, it is quite common for EJB components to rely on the authentication mechanisms provided by the Web container. The Web container provides the user interface for obtaining the caller security credentials and vouches for the identity of users and their access privileges. It is the container's responsibility to set and maintain the authentication boundary between callers and the components deployed in the container. The container also maintains the security context that encapsulates all the authentication information. J2EE uses the notion of protection domains to manage all of the component interactions within the container boundary and to maintain the principal so that the interacting components can trust each other. Figure 5-6 illustrates the security context propagation from the Web tier to the EJB tier.

Figure 5-6. Security context propagation from Web tier to EJB tier

When a Web client invokes an EJB method, the container propagates the security context via the EJB stubs and skeletons. The security context propagation is initiated from the Web container as part of the inbound call, which interacts with the EJBs. It is the EJB container's responsibility to make the representation of the caller's principal identity available to the invoked EJB component. This means that once the user is authenticated in the Web Tier, the authenticated principal identity is applied to the protection domain that manages the container authentication boundary and in turn it makes the principal identity available to the deployed Web and EJB components.

In the case of CORBA- and RMI/IIOP-based clients, the security context propagation among the EJB components and CORBA applications occurs via interoperability, because J2EE-compliant containers support all the requirements of Conformance Level 0 of the Common Security Interoperability version 2 (CSIv2) specifications from Object Management Group (OMG).