Exposing EJBs through CORBA
EJBs running in Geronimo can be exposed through CORBA by creating a Target Security Service (TSS) and configuring the EJB to use that TSS.
Creating a Target Security Service (TSS)
Creating a Target Security Service is done by using XML embedded in an org.apache.geronimo.corba.TSSBean GBean definition as a tssConfig attribute. This GBean can be added to any deployment plan. You can create this XML using an XML editor or a simple text editor. The schema diagram for this XML is shown in the following figure:
The following are the attributes of the tssConfig element:
inherit: Set this attribute to true if the ORB should inherit settings from the ORB within which it is contained.
The following are the child elements of a tssConfig element:
description: A standard Java EE description with a lang attribute.
SSL: Configures an SSL port for CORBA communication.
SECIOP: An alternate secure network transport, currently not supported in Geronimo.
compoundSecMechTypeList: List of one or more compoundSecMech elements. The caller must use one of the methods configured here by using compoundSecMech child elements, or else the connection will fail. This element has an attribute named stateful. When this attribute is set to true, the security information provided by the caller is cached to avoid additional overhead on each call.
compoundSecMech: Configures the authentication and identification strategies supported by this TSS. Each element of this type holds a single configuration. The caller must provide the information required by one of these configurations in order for the communication to proceed.
SSL
The SSL block is used to configure an SSL-enabled port for the CORBA service. The schema diagram for this SSL block is as follows:
The following are the attributes of the SSL element:
port: The network port on which the server will listen.
hostname: Used to set the specific host name or IP address that the service should listen on. This is normally set to 0.0.0.0 or localhost.
The following are the child elements under the SSL element:
supports: Lists the security properties that this SSL connection will support. Common values are Integrity, Confidentiality, EstablishTrustInTarget, and EstablishTrustInClient. Other possible values include DetectReplay and DetectMisordering. Multiple values can be specified, separated by spaces.
requires: Lists the security properties that this SSL connection will require. Common values are Integrity, Confidentiality, EstablishTrustInTarget, and EstablishTrustInClient. Other possible values include DetectReplay and DetectMisordering. Multiple values can be specified, separated by spaces.
trustGroup: Not currently used. This is used to automatically configure clients or hosts that Geronimo trusts.
The following is an explanation of the various values used by the supports and requires elements:
Integrity: The data should not be altered by a third party during communication.
Confidentiality: The data should not be observed by a third party during communication.
EstablishTrustInTarget: The target (for example, a server or EJB) should prove its authenticity to the client (for instance, by providing a valid digital certificate).
EstablishTrustInClient: The client should prove its authenticity to the server. This option is used to obtain the client's digital certificates.
DetectReplay: The server should detect if a third party replays some previous traffic from the client.
DetectMisordering: The server should detect if traffic from the client arrives out of order.
Authentication mechanism
The compoundSecMech block configures a group of security settings that the server accepts in order to identify the incoming user. The schema diagram for this is as follows:
The following are the child elements of compoundSecMech:
GSSUP: Configures the GSSUP protocol, which sends a username and password, along with the connection request. If this is configured, then the server will authenticate the user against a Geronimo security realm, by using the provided username and password. The targetName attribute specifies the name of the Geronimo security realm that should be used to validate the supplied username and password.
sasMech: Groups the SAS settings, which include the various identity token types that the server should accept.
identityTokenTypes: Lists the types of identity tokens that the EJB should accept. If an identity token is accepted by the server, then it is the same as the case where a user provides a username and password and is successfully authenticated. Therefore, it is important that the server trusts either the client or the authority that issued the token.
Identity Tokens
The identityTokenTypes block configures the identity tokens that the server should accept. The schema diagram for this is as follows:
What the various identity tokens and their presence indicate is as follows:
ITTAbsent: This indicates that only a client that provides no identity token should be allowed to connect. This is normally used when the EJB accepts only GSSUP connections.
ITTAnonymous: This indicates that a client should provide a token that asserts that the connection will be anonymous.
ITTPrincipalNameGSSUP: This indicates that the client will provide a principal name. Geronimo will turn this into a Geronimo principal for the purposes of role mapping, and so on. The principal-class attribute specifies the fully-qualified name of the Java principal class that should be used. The domain attribute specifies the login domain name for wrapping the principal. The realm attribute specifies the realm name for wrapping the principal.
ITTDistinguishedName: This indicates that the caller can provide an X.500 distinguished name. A JAAS X500Principal will be created to represent the user with the provided name. The domain attribute specifies the login domain name for wrapping the principal. The realm attribute specifies the realm name for wrapping the principal.
ITTX509CertChain: This indicates that a client may provide a certificate chain. It is possible to configure SSL with EstablishTrustInClient, which requires that the client provide a valid client certificate in order to connect, and then a suitable default principal can be used.
Configuring EJB to use TSS
Once the TSS GBean is created, the EJBs that will be exposed through CORBA should be linked to the TSS using the tss-link child element of session or entity elements in the Geronimo deployment plan.
Sample application exposing EJBs through CORBA
The EJB sample application that we use to expose EJBs through CORBA has a MySessionBean session bean. The deployment descriptor is as follows:
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar id="MyCORBAEjbApp" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"> <display-name>MyCORBAEjbApp</display-name> <enterprise-beans> <session> <description>My Session Bean</description> <display-name>MySessionBean</display-name> <ejb-name>MySessionBean</ejb-name> <home>simple.ejb21.MyServiceHome</home> <remote>simple.ejb21.MyService</remote> <local-home>simple.ejb21.MyServiceLocalHome</local-home> <local>simple.ejb21.MyServiceLocal</local> <ejb-class>simple.ejb21.MyServiceBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <security-identity> <use-caller-identity /> </security-identity> </session> </enterprise-beans> <assembly-descriptor> <security-role003E <description>User role</description> <role-name>ejbuser</role-name> </security-role> <security-role> <description>Administrator role</description> <role-name>ejbadmin</role-name> </security-role> <method-permission> <role-name>ejbuser</role-name> <role-name>ejbadmin</role-name> <method> <ejb-name>MySessionBean</ejb-name> <method-name>convertUSD2EURO</method-name> </method> </method-permission> </assembly-descriptor> </ejb-jar>
The following is a TSS GBean that configures the CORBA EJB exposed through a non-SSL port:
<dep:gbean name="IdentityTokenNoSecurity" class="org.apache. geronimo.corba.TSSBean"> <dep:attribute name="POAName">IdentityTokenNoSecurity </dep:attribute> <dep:reference name="Server"> <dep:name>UnprotectedServer</dep:name> </dep:reference> <dep:xml-attribute name="tssConfig"> <tss:tss xmlns:tss="http://openejb.apache.org/xml/ns/corba- tss-config-2.1" xmlns:sec="http://geronimo.apache.org/xml/ns/ security-1.2"> <tss:compoundSecMechTypeList> <tss:compoundSecMech> <tss:sasMech> <tss:identityTokenTypes> <tss:ITTAnonymous/> <tss:ITTPrincipalNameGSSUP principal-class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/> <tss:ITTDistinguishedName/> <tss:ITTX509CertChain/> </tss:identityTokenTypes> </tss:sasMech> </tss:compoundSecMech> </tss:compoundSecMechTypeList> </tss:tss> </dep:xml-attribute> </dep:gbean>
The following is a TSS GBean that configures the CORBA EJB to be exposed through SSL and users to be authenticated against packt-properties-realm:
<dep:gbean name="SSLWithUsernamePassword" class="org.apache. geronimo.corba.TSSBean"> <dep:attribute name="POAName">SSLWithUsernamePassword </dep:attribute> <dep:reference name="Server"> <dep:name>Server</dep:name> </dep:reference> <dep:xml-attribute name="tssConfig"> <tss:tss xmlns:tss="http://openejb.apache.org/xml/ns/corba- tss-config-2.1" xmlns:sec="http://geronimo.apache.org/xml/ns/ security-1.2"> <tss:SSL port="2001" hostname="localhost"> <tss:supports>Integrity Confidentiality EstablishTrustInTarget </tss:supports> <tss:requires>Integrity Confidentiality</tss:requires> </tss:SSL> <tss:compoundSecMechTypeList> <tss:compoundSecMech> <tss:GSSUP required="true" targetName="packt- properties-realm"/> <tss:sasMech> <tss:identityTokenTypes> <tss:ITTAbsent/> </tss:identityTokenTypes> </tss:sasMech> </tss:compoundSecMech> </tss:compoundSecMechTypeList> </tss:tss> </dep:xml-attribute> </dep:gbean>
The deployment plan openejb-jar.xml is as follows:
<?xml version="1.0" encoding="UTF-8"?> <ejb:openejb-jar xmlns:app="http://geronimo.apache.org/xml/ns/j2ee/application-2.0" ... > <dep:environment> <dep:moduleId> <dep:groupId>packt-samples</dep:groupId> <dep:artifactId>mycorbaejbapp</dep:artifactId> <dep:version>1.0</dep:version> <dep:type>jar</dep:type> </dep:moduleId> <dep:dependencies/> <dep:hidden-classes/> <dep:non-overridable-classes/> </dep:environment> <ejb:enterprise-beans> <ejb:session> <ejb:ejb-name>MySessionBean</ejb:ejb-name> <ejb:jndi-name>ejb/MySessionBean</ejb:jndi-name> <ejb:tss-link>SSLWithUsernamePassword</ejb:tss-link> </ejb:session> </ejb:enterprise-beans> <sec:security> <sec:role-mappings> <sec:role role-name="ejbuser"> <sec:principal class="org.apache.geronimo.security. realm.providers.GeronimoGroupPrincipal" name="User"/> </sec:role> <sec:role role-name="ejbadmin"> <sec:principal class="org.apache.geronimo.security. realm.providers.GeronimoGroupPrincipal" name="Admin"/> </sec:role> </sec:role-mappings> </sec:security> <dep:gbean name="SSLWithUsernamePassword" class="org.apache. geronimo.corba.TSSBean"> ... </dep:gbean> </ejb:openejb-jar>
Notice that the tss-link for MySessionBean is configured to use the SSLWithUsernamePassword TSS. As the GSSUP element configures targetName as packt-properties-realm, the requests to invoke the session bean MySessionBean will be authenticated against packt-properties-realm.
Deploying and running the sample EJB application
Deploy the mycorbaejbapp.jar provided in the samples by using either the Deploy New portlet or the command-line deployer. The application exposes the remote interface, MyService, of MySessionBean through CORBA. In the next section, we will see how this EJB can be invoked through CORBA.