| 17.3. Referencing CORBA EJBs | ||
|---|---|---|
 | Chapter 17. CORBA in Geronimo [DRAFT (1.0)] |  |
| 17.3. Referencing CORBA EJBs | ||
|---|---|---|
| | Chapter 17. CORBA in Geronimo [DRAFT (1.0)] | |
There are two steps to referencing a remote EJB via CORBA: setting up the CSS, and configuring the EJB reference to point to the correct CORBA naming service and use the correct CSS.
The goal of the CSS is to configure what kind of security information Geronimo will provide to the remote CORBA service, as well as to configure the secure network protocol used to connect to the remote service. Like a TSS, a CSS is configured using XML. The XML configuration is embedded in a GBean declaration (see the examples in Section 17.3.1.4, “Sample CSS Configuration”), and that GBean can be listed in any Geronimo deployment plan (though again, it's most often included in the deployment plan for the component that contains the CORBA EJB reference). The CSS configuration looks like this:
The elements and attributes used here are:
Holds all the settings for a CSS configuration
A standard J2EE description block, with a lang attribute to say which language it applies to.
Lists and configures the networking, authentication, and identification strategies supported by this CSS. The target EJB must use one of the methods configured here or else the connection will fail.
Not currently used. The client may need to pass a large amount of security information to the server (potentially including material that must be decrypted, etc.). To avoid additional overhead on each call, a stateful connection can be configured, so the server can cache that information from the first request on. The Geronimo CORBA client does not presently support stateful connections.
Each element of this type holds a single configuration. The service must support the security information provided by one of these configurations in order for the communication to proceed.
An individual compoundSecMech looks like this:
The elements introduced here are:
Configures a SSL transport to communicate with the remote CORBA EJB.
Not currently used. An alternate secure network transport, SECIOP is not currently supported by Geronimo.
A group of elements used to configure authentication. This is not actually an element itself, just a placeholder for the elements in the group.
Hold elements used to configure identification.
The SSL block is used to configure a CORBA client to communicate with the server over SSL:
The elements used here are:
Not currently used.
A list of security properties that this SSL connection will support. The protocol will allow but not require these attributes to be negotiated for the connection. The most common values are Integrity, Confidentiality, EstablishTrustInTarget, and EstablishTrustInClient. Other possible values for SSL include DetectReplay and DetectMisordering. Multiple values can be provided and should be listed separated by spaces.
A list of security properties that this SSL connection requires. If a client cannot support these, the connection will be refused. The most common values are Integrity, Confidentiality, EstablishTrustInTarget, and EstablishTrustInClient. Other possible values for SSL include DetectReplay and DetectMisordering. Multiple values can be provided and should be listed separated by spaces.
Not currently used. This is used to configure clients or hosts that Geronimo trusts automatically, but it is not enabled in Geronimo 1.0.
The values used for the supports and requires elements are:
Table 17.2. CSS Configuration: CORBA SSL Attributes
| Value | Description |
|---|---|
| Integrity | The data en route should not be able to be altered by a third party. |
| Confidentiality | The data en route should not be able to be observed by a third party. |
| EstablishTrustInTarget | The target (e.g. server or EJB) should prove its validity to the client (e.g. by providing a valid SSL certificate) |
| EstablishTrustInClient | The client should prove it's validity to the server. In practice, this option is used to require client certificates. |
| DetectReplay | The server should not be fooled if a third party replays some previous traffic from the client. |
| DetectMisordering | The server should notice if traffic from the client arrives out of order. |
With these elements, a CORBA client can provide authentication information to the remote server, which will end up executing a login on the server side to decide whether to permit access to the remote EJB.
The elements and attributes introduced here are:
This indicates that all callers will use a specific configured username and password to authenticate to the remote service.
The username to pass as part of the authentication request.
The password to pass as part of the authentication request.
The domain name to send for this username and password. The server is typically looking for a username and password associated with a specific domain name. For example, when Geronimo is acting as the server, the domain name is used as the name of the security realm to authenticate against -- and other servers may have similar behavior.
This indicates the each user in the local Geronimo server will pass their own username and password to the remote CORBA server (or a separate username and password associated with their account for purposes of communicating with this CORBA service). In either case, the security realm that the current user logged in to requires special configuration, as normally the password is not stored for later use.
The domain here is used for two purposes. First, the Geronimo CORBA client looks in the current user's credentials for a named credential stored under this name. If it finds one, that defines the username and password to send to the server. Also, it sends the username and password with this domain name, and the server is typically looking for a username and password associated with a specific domain name. For example, when Geronimo is acting as the server, the domain name is used as the name of the security realm to authenticate against -- and other servers may have similar behavior.
![[Warning]](images/warning.png) | Warning |
|---|---|
GSSUPDynamic authentication does not work in Geronimo 1.0, but does work in release 1.0.1 and beyond. | |
In order for GSSUPDynamic authentication to work, the Geronimo security realm that a user logs in to must save their username and password so that they are available to pass on to the remote CORBA service later. In practice, to store the username and password, an additional login module must be added to the Geronimo security realm. (For more details on configuring security realms and login modules, see Chapter 9, Security Configuration [DRAFT (1.0-pre)].) The settings for this login module are:
Table 17.3. CSS: Login Module to Save Username & Password
| Login Module Class: | org.apache.geronimo.security.jaas.NamedUPCredentialLoginModule |
| Configuration Options: | org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name (set the value for this option to a name to store the credentials under, and the web service will use the same name to pick the credentials it wants) |
| Control Flag: | REQUIRED |
| Server Side: | true |
Currently this module cannot be added through the security realm wizard in the Console, though you can create a new security realm, select Other as the type, and then manually enter in the settings for both the main login module and this one. Alternately, you can write a security realm deployment plan like the one in Example 17.6, “Security Realm Plan for a CORBA Client with GSSUPDynamic” and deploy that using the normal command-line deployment tool.
Example 17.6. Security Realm Plan for a CORBA Client with GSSUPDynamic
This plan uses the standard Geronimo properties login module, and adds the login module described above in addition.
<configuration configId="MyRealm"
xmlns="http://geronimo.apache.org/xml/ns/deployment-1.0">
<gbean name="MyRealm"
class="org.apache.geronimo.security.realm.GenericSecurityRealm">
<attribute name="realmName">MyRealm</attribute>
<reference name="ServerInfo">
<gbean-name>geronimo.server:J2EEApplication=null,
J2EEModule=geronimo/j2ee-system/1.0/car,
J2EEServer=geronimo,j2eeType=GBean,name=ServerInfo
</gbean-name>
</reference>
<reference name="LoginService">
<gbean-name>geronimo.server:J2EEApplication=null,
J2EEModule=geronimo/j2ee-security/1.0/car,
J2EEServer=geronimo,j2eeType=JaasLoginService,
name=JaasLoginService
</gbean-name>
</reference>
<xml-reference name="LoginModuleConfiguration">
<log:login-config
xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-1.0">
<log:login-module control-flag="REQUIRED"
server-side="true" wrap-principals="false">
<log:login-domain-name>
MainDomain
</log:login-domain-name>
<log:login-module-class>
org.apache.geronimo.security.realm.providers.
PropertiesFileLoginModule
</log:login-module-class>
<log:option name="usersURI">
var/security/users.properties
</log:option>
<log:option name="groupsURI">
var/security/groups.properties
</log:option>
</log:login-module>
<log:login-module control-flag="REQUIRED"
server-side="true" wrap-principals="false">
<log:login-domain-name>
NamedDomain
</log:login-domain-name>
<log:login-module-class>
org.apache.geronimo.security.jaas.NamedUPCredentialLoginModule
</log:login-module-class>
<log:option
name="org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name"
>
CORBACredentials
</log:option>
</log:login-module>
</log:login-config>
</xml-reference>
</gbean>
</configuration>Note that the GBean names and class names in this example were split across multiple lines to fit the page, and will need to be combined again to deploy properly.
With these elements, a CORBA client can provide a principal name to the remote server. The server must trust the client already (for example, by requiring an SSL connection with client certificates), as it will just execute its authorization based on the provided principal name.
The elements and attributes introduced here are:
If present, the client will never send any identification information to the server.
If present, the client will send an identification token asserting that it is anonymous. This may be treated differently than not sending anything at all, but the end result is likely to be similar.
If present, the client always sends a fixed principal name to the remote CORBA service, no matter what user is locally executing the CORBA client.
The fixed principal name that should be sent to the server.
The OID that should be sent along with the principal name. If not specified, defaults to 2.23.130.1.1.1
If present, the client sends the name of a principal in the current user's Subject to the remote CORBA service. The attributes on this element indicate which principal name to send.
The principal class to look for in the current user's Subject. The principal name sent will always come from a principal of this type.
If the domain is specified, advanced role mapping must be enabled for the security realm that handled this user's login, and a principal will only count if it is of the correct class and came from a login domain with this name.
If the realm is specified, advanced role mapping must be enabled for the security realm that handled this user's login, and a principal will only count if it is of the correct class and came from a security realm with this name.
The OID that should be sent along with the principal name. If not specified, defaults to 2.23.130.1.1.1
A sample CSS might look like this:
Example 17.7. CSS Configuration: GSSUP Only
This CSS configures a standard SSL connection to the naming service, and a standard SSL connection to the remote CORBA service, providing GSSUP information only. It gets separate GSSUP information for each client user, assuming that information was stored by a security realm configured like in Example 17.6, “Security Realm Plan for a CORBA Client with GSSUPDynamic” (that is, the username and password are stored by the security realm under the name "CORBACredentials").
<gbean name="CSS-SSLWithGSSUP" class="org.openejb.corba.CSSBean">
<reference name="ThreadPool">
<application>null</application>
<moduleType>J2EEModule</moduleType>
<module>geronimo/j2ee-server/1.0/car</module>
<name>DefaultThreadPool</name>
</reference>
<reference name="TransactionContextManager">
<application>null</application>
<moduleType>J2EEModule</moduleType>
<module>geronimo/j2ee-server/1.0/car</module>
<name>TransactionContextManager</name>
</reference>
<attribute name="configAdapter">
org.openejb.corba.sunorb.SunORBConfigAdapter
</attribute>
<attribute name="description">CSS-SSLWithGSSUP</attribute>
<xml-attribute name="nssConfig">
<css:css
xmlns:css="http://www.openejb.org/xml/ns/corba-css-config-2.0">
<css:compoundSecMechTypeList>
<css:compoundSecMech>
<css:SSL>
<css:supports>
Integrity Confidentiality EstablishTrustInTarget
</css:supports>
<css:requires/>
</css:SSL>
</css:compoundSecMech>
</css:compoundSecMechTypeList>
</css:css>
</xml-attribute>
<xml-attribute name="cssConfig">
<css:css
xmlns:css="http://www.openejb.org/xml/ns/corba-css-config-2.0">
<css:compoundSecMechTypeList>
<css:compoundSecMech>
<css:SSL>
<css:supports>
Integrity Confidentiality EstablishTrustInTarget
</css:supports>
<css:requires>
Integrity Confidentiality EstablishTrustInTarget
</css:requires>
</css:SSL>
<css:GSSUPDynamic domain="CORBACredentials"/>
<css:sasMech>
<css:ITTAbsent/>
</css:sasMech>
</css:compoundSecMech>
</css:compoundSecMechTypeList>
</css:css>
</xml-attribute>
</gbean>Another example might look like this:
Example 17.8. CSS Configuration: Client Cert and Identity
This CSS configures a standard SSL connection to the naming service, and an SSL connection to the remote CORBA service using a client certificate, providing a principal to the remote service. It provides a separate principal name for each client user, based on the GeronimoUserPrincipal configured for that user by the security realm when they originally logged in.
<gbean name="CSS-ClientCert" class="org.openejb.corba.CSSBean">
<reference name="ThreadPool">
<application>null</application>
<moduleType>J2EEModule</moduleType>
<module>geronimo/j2ee-server/1.0/car</module>
<name>DefaultThreadPool</name>
</reference>
<reference name="TransactionContextManager">
<application>null</application>
<moduleType>J2EEModule</moduleType>
<module>geronimo/j2ee-server/1.0/car</module>
<name>TransactionContextManager</name>
</reference>
<attribute name="configAdapter">
org.openejb.corba.sunorb.SunORBConfigAdapter
</attribute>
<attribute name="description">CSS-ClientCert</attribute>
<xml-attribute name="nssConfig">
<css:css
xmlns:css="http://www.openejb.org/xml/ns/corba-css-config-2.0">
<css:compoundSecMechTypeList>
<css:compoundSecMech>
<css:SSL>
<css:supports>
Integrity Confidentiality EstablishTrustInTarget
</css:supports>
<css:requires/>
</css:SSL>
</css:compoundSecMech>
</css:compoundSecMechTypeList>
</css:css>
</xml-attribute>
<xml-attribute name="cssConfig">
<css:css
xmlns:css="http://www.openejb.org/xml/ns/corba-css-config-2.0">
<css:compoundSecMechTypeList>
<css:compoundSecMech>
<css:SSL>
<css:supports>
Integrity Confidentiality EstablishTrustInTarget
EstablishTrustInClient
</css:supports>
<css:requires>
Integrity Confidentiality EstablishTrustInTarget
EstablishTrustInClient
</css:requires>
</css:SSL>
<css:sasMech>
<css:ITTPrincipalNameDynamic
principal-class="org.apache.geronimo.security.realm.providers.
GeronimoUserPrincipal"
/>
</css:sasMech>
</css:compoundSecMech>
</css:compoundSecMechTypeList>
</css:css>
</xml-attribute>
</gbean>Note that the principal class name has been split across lines to fit the page, but must be combined if this example is deployed!
With the CSS (and, if necessary, security realm) configured, CORBA can be easily enabled for a standard EJB reference. The Geronimo deployment plan provides name of the CSS to use to contact the server, as well as a URL to reach the CORBA naming service and the name of the EJB to look up there. Once configured, the EJB Home can be looked up in JNDI as usual. The following sections describe this process in detail.
A web application or EJB can declare an EJB reference to the remote EJB using the standard J2EE syntax .
Example 17.9. CORBA EJB Reference: J2EE Deployment Descriptor
A reference to a CORBA EJB is declared in either web.xml or ejb-jar.xml and must use the EJB's remote interfaces:
<ejb-ref> <ejb-ref-name>corba/SomeSession</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>some.package.SomeSessionHome</home> <remote>some.package.SomeSession</remote> </ejb-ref>
The Geronimo deployment plan resolves the EJB reference to a specific EJB in the CORBA environment. For a detailed description of the deployment plan elements related to CORBA EJB references, see Section 11.3.4.2.2, “Referring to Remote EJBs via CORBA” and Section 12.3.6.2.1, “References to EJBs via CORBA”. However, the example here shows the usual syntax:
Example 17.10. CORBA EJB Reference: Geronimo Deployment Plan
The geronimo-web.xml or openejb-jar.xml maps the EJB reference to a CSS, a CORBA naming service, and a specific EJB name within that naming service. In addition, this is typically where the CSS is defined. Finally, an import pointing to the main Geronimo CORBA configuration ensures that CORBA service will be running whenever this application is started.
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.0"
configId="TestWeb">
<!-- Make sure the CORBA infrastructure is running -->
<import>
<uri>geronimo/j2ee-corba/1.0/car</uri>
</import>
<!-- Resolve the EJB reference -->
<naming:ejb-ref>
<naming:ref-name>corba/SomeSession</naming:ref-name>
<naming:ns-corbaloc>
corbaloc::localhost:1050/NameService
</naming:ns-corbaloc>
<naming:name>CORBASessionBean</naming:name>
<naming:css-link>CSS-SSLWithGSSUP</naming:css-link>
</naming:ejb-ref>
<!-- Define the CSS used by the EJB reference -->
<gbean name="CSS-SSLWithGSSUP" class="org.openejb.corba.CSSBean"
xmlns="http://geronimo.apache.org/xml/ns/deployment-1.0">
... (CSS configuration here) ...
</gbean>
</web-app>An application looks up a CORBA EJB Home in JNDI like any other EJB reference. The name to look up is java:comp/env/ plus the ejb-ref-name specified in the J2EE deployment descriptor. In addition, the object returned from JNDI cannot be cast directly to an EJB home interface, but must be run through PortableRemoteObject.narrow to create the final EJBHome instance.
Example 17.11. CORBA EJB Reference: Accessing the EJB
The code to look up the EJB reference configured in the previous examples would look like this:
Context ctx = new InitialContext();
Object fromJNDI = ctx.lookup("java:comp/env/corba/SomeSession");
SomeSessionHome home = (SomeSessionHome)
PortableRemoteObject.narrow(fromJNDI,SomeSessionHome.class);
SomeSession remote = home.create();
// use the session bean| |  | |
| 17.2. Exposing EJBs via CORBA |  | Part IV. Advanced Geronimo |