The EJB interoperability protocol is based on Internet Inter-ORB Protocol (IIOP/GIOP 1.2) and the Common Secure Interoperability version 2 (CSIv2) CORBA Secure Interoperability specification.
Enterprise beans that are deployed in one vendor’s server product are often accessed from Java EE client components that are deployed in another vendor’s product. 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. IOR configurations are defined in Chapter 24 of the CORBA/IIOP specification, Secure Interoperability. This chapter can be downloaded from http://www.omg.org/cgi-bin/doc?formal/02-06-60.
The EJB interoperability protocol is defined in Chapter 14, Support for Distribution and Interoperability, of the EJB specification, which can be downloaded from http://jcp.org/en/jsr/detail?id=220.
Based on application requirements, IORs are configured in vendor-specific XML files, such as sun-ejb-jar.xml, instead of in standard application deployment descriptor files, such as ejb-jar.xml.
For a Java EE application, IOR configurations are specified in Sun-specific xml files, for example, sun-ejb-jar_2_1-1.dtd. The ior-security-config element describes the security configuration information for the IOR. A description of some of the major subelements is provided below.
transport-config
This is the root element for security between the endpoints. It contains the following elements:
integrity: This element specifies whether the target supports integrity-protected messages for transport. The values are NONE, SUPPORTED, or REQUIRED.
confidentiality: This element specifies whether the target supports privacy-protected messages (SSL) for transport. The values are NONE, SUPPORTED, or REQUIRED.
establish-trust-in-target: This element 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 values are NONE, SUPPORTED, or REQUIRED.
establish-trust-in-client: This element specifies whether or not the target component is capable of authenticating a client for transport (target asks the client to authenticate itself). The values are NONE, SUPPORTED, or REQUIRED.
as-context
This is the element that describes the authentication mechanism (CSIv2 authentication service) that will be used to authenticate the client. If specified, it will be the username-password mechanism.
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.
The as-context element contains the following elements:
required: This element specifies 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. The element value is either true or false.
auth-method: This element specifies the authentication method. The only supported value is USERNAME_PASSWORD.
realm: This element specifies the realm in which the user is authenticated. Must be a valid realm that is registered in a server configuration.
sas-context
This element is related to the CSIv2 security attribute service. It describes the sas-context fields.
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.
The sas-context element contains the caller-propagation subelement. This element indicates if the target will accept propagated caller identities. The values are NONE or SUPPORTED.
The following is an example that defines security for an IOR:
<sun-ejb-jar> <enterprise-beans> <unique-id>1</unique-id> <ejb> <ejb-name>HelloWorld</ejb-name> <jndi-name>HelloWorld</jndi-name> <ior-security-config> <transport-config> <integrity>NONE</integrity> <confidentiality>NONE</confidentiality> <establish-trust-in-target> NONE </establish-trust-in-target> <establish-trust-in-client> NONE </establish-trust-in-client> </transport-config> <as-context> <auth-method>USERNAME_PASSWORD</auth-method> <realm>default</realm> <required>true</required> </as-context> <sas-context> <caller-propagation>NONE</caller-propagation> </sas-context> </ior-security-config> <webservice-endpoint> <port-component-name>HelloIF</port-component-name> <endpoint-address-uri> service/HelloWorld </endpoint-address-uri> <login-config> <auth-method>BASIC</auth-method> </login-config> </webservice-endpoint> </ejb> </enterprise-beans> </sun-ejb-jar>