Sun Microsystem Inc
Bean Provider’s responsibilities |
Enterprise JavaBeans v1.1, Final Release |
Security management |
The management of caller principals passed on enterprise bean invocations (i.e. principal delegation) is set up by the Deployer and System Administrator in a Container-specific way. The Bean Provider and Application Assembler should describe all the requirements for the caller’s principal management of inter-enterprise bean invocations as part of the description. The default principal management (in the absence of other deployment instructions) is to propagate the caller principal from the caller to the callee. (That is, the called enterprise bean will see the same returned value of the EJBContext.getCallerPrincipal() as the calling enterprise bean.)
15.2.2 Resource access
Section 14.4 defines the protocol for accessing resource managers, including the requirements for security management.
15.2.3 Access of underlying OS resources
The EJB architecture does not define the operating system principal under which enterprise bean methods execute. Therefore, the Bean Provider cannot rely on a specific principal for accessing the underlying OS resources, such as files. (See subsection 15.6.8 for the reasons behind this rule.)
We believe that most enterprise business applications store information in resource managers such as relational databases rather than in resources at the operating system levels. Therefore, this rule should not affect the portability of most enterprise beans.
15.2.4 Programming style recommendations
The Bean Provider should neither implement security mechanisms nor hard-code security policies in the enterprise beans’ business methods. Rather, the Bean Provider should rely on the security mechanisms provided by the EJB Container, and should let the Application Assembler and Deployer define the appropriate security policies for the application.
The Bean Provider and Application Assembler may use the deployment descriptor to convey secu- rity-related information to the Deployer. The information helps the Deployer to set up the appropriate security policy for the enterprise bean application.
15.2.5 Programmatic access to caller’s security context
Note: In general, security management should be enforced by the Container in a manner that is transparent to the enterprise beans’ business methods. The security API described in this section should be used only in the less frequent situations in which the enterprise bean business methods need to access the security context information.
221 |
11/24/99 |
Sun Microsystems Inc.
Security management |
Enterprise JavaBeans v1.1, Final Release |
Bean Provider’s responsibilities |
The javax.ejb.EJBContext interface provides two methods (plus two deprecated methods that were defined in EJB 1.0) that allow the Bean Provider to access security information about the enterprise bean’s caller.
public interface javax.ejb.EJBContext {
...
//
//The following two methods allow the EJB class
//to access security information.
//
java.security.Principal getCallerPrincipal(); boolean isCallerInRole(String roleName);
//
// The following two EJB 1.0 methods are deprecated.
//
java.security.Identity getCallerIdentity();
boolean isCallerInRole(java.security.Identity role);
...
}
The Bean Provider can invoke the getCallerPrincipal and isCallerInRole methods only in the enterprise bean’s business methods for which the Container has a client security context, as specified in Table 2 on page 60, Table 3 on page 70, and Table 4 on page 111. If they are invoked when no security context exists, they should throw the java.lang.IllegalStateException runtime exception.
The getCallerIdentity() and isCallerInRole(Identity role) methods are deprecated in EJB 1.1. The Bean Provider must use the getCallerPrincipal() and isCallerInRole(String roleName) methods for new enterprise beans.
An EJB 1.1 compliant container may choose to implement the two deprecated methods as follows.
•A Container that does not want to provide support for this deprecated method should throw a
RuntimeException (or subclass of RuntimeException) from the getCallerIdentity() method.
•A Container that wants to provide support for the getCallerIdentity() method should return an instance of a subclass of the java.security.Identity abstract class from the
11/24/99 |
222 |
Sun Microsystem Inc
Bean Provider’s responsibilities |
Enterprise JavaBeans v1.1, Final Release |
Security management |
method. The getName() method invoked on the returned object must return the same value that getCallerPrincipal().getName() would return.
•A Container that does not want to provide support for this deprecated method should throw a
RuntimeException (or subclass of RuntimeException) from the isCallerInRole(Identity identity) method.
•A Container that wants to implement the isCallerInRole(Identity identity) method should implement it as follows:
public isCallerInRole(Identity identity) { return isCallerInRole(identity.getName());
}
15.2.5.1 Use of getCallerPrincipal()
The purpose of the getCallerPrincipal() method is to allow the enterprise bean methods to obtain the current caller principal’s name. The methods might, for example, use the name as a key to information in a database.
An enterprise bean can invoke the getCallerPrincipal() method to obtain a java.security.Principal interface representing the current caller. The enterprise bean can then obtain the distinguished name of the caller principal using the getName() method of the java.security.Principal interface.
The meaning of the current caller, the Java class that implements the java.security.Principal interface, and the realm of the principals returned by the getCallerPrincipal() method depend on the operational environment and the configuration of the application.
An enterprise may have a complex security infrastructure that includes multiple security domains. The security infrastructure may perform one or more mapping of principals on the path from an EJB caller to the EJB object. For example, an employee accessing his company over the Internet may be identified by a userid and password (basic authentication), and the security infrastructure may authenticate the principal and then map the principal to a Kerberos principal that is used on the enterprise’ s intranet before delivering the method invocation to the EJB object. If the security infrastructure performs principal mapping, the getCallerPrincipal() method returns the principal that is the result of the mapping, not the original caller principal. (In the previous example, getCallerPrincipal() would return the Kerberos principal.) The management of the security infrastructure, such as principal mapping, is performed by the System Administrator role; it is beyond the scope EJB specification.
223 |
11/24/99 |
Sun Microsystems Inc.
Security management |
Enterprise JavaBeans v1.1, Final Release |
Bean Provider’s responsibilities |
The following code sample illustrates the use of the getCallerPrincipal() method.
public class EmployeeServiceBean implements SessionBean { EJBContext ejbContext;
public void changePhoneNumber(...) {
...
//Obtain the default initial JNDI context. Context initCtx = new InitialContext();
//Look up the home interface of the EmployeeRecord
//enterprise bean in the environment.
Object result = initCtx.lookup( "java:comp/env/ejb/EmplRecord");
// Convert the result to the proper type. EmployeeRecordHome emplRecordHome = (EmployeeRecordHome)
javax.rmi.PortableRemoteObject.narrow(result,
EmployeeRecordHome.class);
// obtain the caller principal.
callerPrincipal = ejbContext.getCallerPrincipal();
//obtain the caller principal’s name. callerKey = callerPrincipal.getName();
//use callerKey as primary key to EmployeeRecord finder EmployeeRecord myEmployeeRecord =
emplRecordHome.findByPrimaryKey(callerKey);
//update phone number myEmployeeRecord.changePhoneNumber(...);
...
}
}
In the previous example, the enterprise bean obtains the principal name of the current caller and uses it as the primary key to locate an EmployeeRecord Entity object. This example assumes that application has been deployed such that the current caller principal contains the primary key used for the identification of employees (e.g. employee number).
15.2.5.2 Use of isCallerInRole(String roleName)
The main purpose of the isCallerInRole(String roleName) method is to allow the Bean Provider to code the security checks that cannot be easily defined declaratively in the deployment descriptor using method permissions. Such a check might impose a role-based limit on a request, or it might depend on information stored in the database.
The enterprise bean code uses the isCallerInRole(String roleName) method to test whether the current caller has been assigned to a given security role. Security roles are defined by the Application Assembler in the deployment descriptor (see Subsection 15.3.1), and are assigned to principals or principal groups that exist in the operational environment by the Deployer.
11/24/99 |
224 |