EJB-Tier Security

The following sections describe declarative and programmatic security mechanisms that can be used to protect resources in the EJB tier. The protected resources include methods of enterprise beans that are called from application clients, web components, or other enterprise beans.

Declaring method permissions

Mapping roles to J2EE users and groups

Declaring Method Permissions

After you've defined the roles (see Setting Up Security Roles), you can define the method permissions of an enterprise bean. Method permissions indicate which roles are allowed to invoke which methods. You can define method permissions in various ways.

You can apply method permissions to all the methods of the specified enterprise bean's home, component, and web service endpoint interfaces.

You can apply method permissions to the specified method of the enterprise bean. If the enterprise bean contains multiple methods having the same method name, the method permission applies to all the methods.

If the enterprise bean contains multiple methods having the same method name but the methods have different method parameters (such as create(a,b) and create(a,b,c)), you can apply method permissions by specifying the method parameters.

In general, use deploytool to specify method permissions by mapping roles to methods:

Select the enterprise bean.

Select the Security tab.

Select the interface type (local, local home, remote, or remote home). The table displays methods contained in the selected interface. If no interfaces have been defined, the interface buttons will be disabled.

In the Method Permissions table, select the method for which you want to specify permissions.

In the Availability column for that method, select Sel Roles from the drop-down list for that method.

Select a role's checkbox if that role should be allowed to invoke a method.

Configuring IOR Security

Enterprise beans that are deployed in one vendor's server product are often accessed from J2EE client components that are deployed in another vendor's product. Common Secure Interoperability version 2 (CSIv2), a CORBA/IIOP-based standard interoperability protocol, addresses this situation by providing authentication, protection of integrity and confidentiality, and principal propagation for invocations on enterprise beans, where the invocations take place over an enterprise's intranet.

CSIv2 configuration settings are specified in the Interoperable Object Reference (IOR) of the target enterprise bean. In the IOR security configuration dialog box, you can specify the security information for the IOR.

To get to the IOR security configuration dialog box, select the enterprise bean to which you want to add the settings in the deploytool tree view. From the General tabbed pane, select Sun-specific Settings. In the General subpane of the EJB Settings pane, press the IOR button.

The Integrity field specifies whether the target supports integrity-protected messages for transport.

The Confidentiality field specifies whether the target supports privacy-protected messages (SSL) for transport.

The Establish Trust In Target field specifies whether or not the target component is capable of authenticating to a client for transport. It is used for mutual authentication (to validate the server's identity).

The Establish Trust In Client field specifies whether or not the target component is capable of authenticating a client for transport (target asks the client to authenticate itself).

In each of these fields, you can select whether the item is supported, required, or not activated (none).

Use the Required drop-down list to identify whether the authentication method specified is required to be used for client authentication. Setting this field to true indicates that the authentication method specified is required. Setting this field to false indicates that the method authentication is not required.

Use the Authorization Method drop-down list to authenticate the client. The only supported value is USERNAME_PASSWORD.

Use the Realm field to identify the realm in which the user is authenticated.

In the Duke's Bank example, the As Context setting is used to require client authentication (with user name and password) when access to protected methods in the AccountControllerBean and CustomerControllerBean components is attempted.

In the Sas Context subpane, use the Caller Propagation drop-down list to identify whether or not the target component will accept propagated caller identities.

In the Duke's Bank example, the Sas Context setting is set to Supported for the AccountBean, CustomerBean, and TxBean components, indicating that these target components will accept propagated caller identities.

Using Programmatic Security in the EJB Tier

Programmatic security in the EJB tier consists of the getCallerPrincipal and the isCallerInRole methods. You can use the getCallerPrincipal method to determine the caller of the enterprise bean and use the isCallerInRole method to determine whether the caller has the specified role.

The getCallerPrincipal method of the EJBContext interface returns the java.security.Principal object that identifies the caller of the enterprise bean. (In this case, a principal is the same as a user.) In the following example, the getUser method of an enterprise bean returns the name of the J2EE user that invoked it:

public String getUser() {
   return context.getCallerPrincipal().getName();
}

You can determine whether an enterprise bean's caller belongs to the Customer role.

Unauthenticated User Name

Web applications accept unauthenticated web clients and allow these clients to make calls to the EJB container. The EJB specification requires a security credential for accessing EJB methods. Typically, the credential will be that of a generic unauthenticated user.