| OracleŽ Application Server Containers for J2EE Security Guide 10g (9.0.4) Part Number Part No. B10325-02 |
|
Oracle Application Server Containers for J2EE supports the Common Secure Interoperability Version 2 protocol (CSIv2). CSIv2 specifies different conformance levels; Oracle Application Server Containers for J2EE complies with the EJB specification, which requires conformance level 0.
This chapter covers the following topics:
|
Note: If your application uses JAAS, you must configure the JAAS Provider to use CSIv2; see Table 3-8, "RealmLoginModule Options" for details. |
Common Secure Interoperability version 2 (CSIv2) is an Object Management Group (OMG) standard for a secure interoperable wire protocol that supports authorization and identity delegation. You configure CSIv2 properties in three different locations:
These configuration files are discussed in "CSIv2 Security Properties in internal-settings.xml", "EJB Client Security Properties in ejb_sec.properties", "CSIv2 Security Properties in orion-ejb-jar.xml", and "EJB Client Security Properties in ejb_sec.properties".
You specify server security properties in internal-settings.xml.
This file specifies certain properties as values within <sep-property> entities. Table 14-1, "EJB Server Security Properties" contains a list of properties.
The table refers to keystore and truststore files, which use the Java Key Store (JKS), a JDK-specified format, to store keys and certificates. A keystore stores a map of private keys and certificates. A truststore stores trusted certificates for the certificate authorities (CAs; such as VeriSign and Thawte).
|
Note:
In Table 14-1, the properties |
If Oracle Application Server Containers for J2EE is started by the Oracle Process Management Notification service (OPMN) in an OracleAS (as opposed to standalone) environment, then ports specified in internal-settings.xml are ignored. If OPMN is configured to disable IIOP for a particular Oracle Application Server Containers for J2EE instance, then, even though IIOP may be enable through internal-settings.xml (as pointed to by server.xml), IIOP is not enabled.
The following example shows a typical internal-settings.xml file:
<server-extension-provider name="IIOP" class="com.oracle.iiop.server.IIOPServerExtensionProvider"> <sep-property name="port" value="5555" /> <sep-property name="host" value="localhost" /> <sep-property name="ssl" value="false" /> <sep-property name="ssl-port" value="5556" /> <sep-property name="ssl-client-server-auth-port" value="5557" /> <sep-property name="keystore" value="keystore.jks" /> <sep-property name="keystore-password" value="123456" /> <sep-property name="truststore" value="truststore.jks" /> <sep-property name="truststore-password" value="123456" /> <sep-property name="trusted-clients" value="*" /> </server-extension-provider>
Here is the DTD for internal-settings.xml:
<!-- A server extension provider that is to be plugged in to the server. --> <!ELEMENT server-extension-provider (sep-property*) (#PCDATA)> <!ATTLIST server-extension-provider name class CDATA #IMPLIED> <!ELEMENT sep-property (#PCDATA)> <!ATTLIST sep-property name value CDATA #IMPLIED> <!-- This file contains internal server configuration settings. --> <!ELEMENT internal-settings (server-extension-provider*)>
This section discusses the semantics of the values you set within the <sep-property> element in internal_settings.xml. For details of syntax, see "EJB Server Security Properties in internal-settings.xml" .
To use the CSIv2 protocol with Oracle Application Server Containers for J2EE, you must both set ssl to true and specify an IIOP/SSL port (ssl-port).
ssl to true, then CSIv2 is not enabled. Setting ssl to true permits clients and servers to use CSIv2, but does not require them to communicate using SSL.
ssl-port, then no CSIv2 component tag is inserted by the server into the IOR, even if you configure an <ior-security-config> entity in orion-ejb-jar.xml.
When IIOP/SSL is enabled on the server, Oracle Application Server Containers for J2EE listens on two different sockets--one for server authentication alone and one for server and client authentication. You specify the server authentication port within the <sep-property> element; the server and client authentication listener uses the port number immediately following.
For SSL clients using server authentication alone, you can specify:
If you specify neither keystore nor truststore, the handshake may fail if there are no default truststores established by the security provider.
SSL clients using client-side authentication must specify both a keystore and a truststore. The certificate from the keystore is used for client authentication.
If the client does not use client-side SSL authentication, you must set client.sendpassword in the ejb_sec.properties file in order for the client runtime to insert a security context and send the user name and password. You must also set server.trustedhosts to include your server.
If the client does use client-side SSL authentication, the server extracts the DistinguishedName from the client's certificate and then looks it up in the corresponding user manager; it does not perform password authentication.
Two types of trust relationships exist:
Clients list trusted servers in the EJB property oc4j.iiop.trustedServers. See Table 14-2, "EJB Client Security Properties" for details. Servers list trusted clients in the trusted-client property of the <sep-property> element in internal-settings.xml. See "EJB Server Security Properties in internal-settings.xml" for details.
Conformance level 0 of the EJB standard defines two ways of handling trust relationships:
trusted-client list or both
Oracle Application Server Containers for J2EE provides both kinds of trust; you configure trust using the bean's <ior-security-config> element in orion-ejb-jar.xml. See "CSIv2 Security Properties in orion-ejb-jar.xml" for details.
This section discusses the CSIv2 security properties for an EJB. You configure each individual bean's CSIv2 security policies in its orion-ejb-jar.xml. The CSIv2 security properties are specified within <ior-security-config> elements. Each element contains a <transport-config> element, an <as-context> element, and an <sas-context> element.
This element specifies the transport security level. Each element within <transport-config> must be set to supported, required, or none. None means that the bean neither supports nor uses that feature; supports means that the bean permits the client to use the feature; required means that the bean insists that the client use the feature. The elements are:
<integrity>--Is there a guarantee that all transmissions are received exactly as they were transmitted?
<confidentiality>--Is there a guarantee that no third party was able to read transmissions?
<establish-trust-in-target>--Does the server authenticate itself to the client?
<establish-trust-in-client>--Does the client authenticate itself to the server?
This element specifies the message-level authentication properties.
<auth-method>--Must be set to either username_password or none. If set to username_password, beans use user names and passwords to authenticate the caller.
<realm>--Must be set to default at this release.
<required>--If set to true, the bean requires the caller to specify a user name and password.
This element specifies the identity delegation properties. It has one element, <caller-propagation>, which can be set to supported, required, or none. If the <caller-propagation> element is set to supported, then this bean accepts delegated identities from intermediate servers. If it is set to required, then this bean requires all other beans to transmit delegated identities. If set to none, this bean does not support identity delegation.
An example:
<ior-security-config> <transport-config> <integrity>supported</integrity> <confidentiality>supported</confidentiality> <establish-trust-in-target>supported</establish-trust-in-target> <establish-trust-in-client>supported</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>supported</caller-propagation> </sas-context> </ior-security-config>
The DTD for the <ior-security-config> element is:
<!ELEMENT ior-security-config (transport-config?, as-context? sas-context?) > <!ELEMENT transport-config (integrity, confidentiality, establish-trust-in-target, establish-trust-in-client) > <!ELEMENT as-context (auth-method, realm, required) > <!ELEMENT sas-context (caller-propagation) > <!ELEMENT integrity (#PCDATA) > <!ELEMENT confidentiality (#PCDATA)> <!ELEMENT establish-trust-in-target (#PCDATA) > <!ELEMENT establish-trust-in-client (#PCDATA) > <!ELEMENT auth-method (#PCDATA) > <!ELEMENT realm (#PCDATA) > <!ELEMENT required (#PCDATA)> <!-- Must be true or false --> <!ELEMENT caller-propagation (#PCDATA) >
Any client, whether running inside a server or not, has EJB security properties. Table 14-2 lists the EJB client security properties controlled by the ejb_sec.properties file. By default, Oracle Application Server Containers for J2EE searches for this file in the current directory when running as a client or in J2EE_HOME/config when running in the server. You can specify this file's location explicitly with -Dejb_sec_properties_location=pathname.
|
|
![]() Copyright © 1996, 2003 Oracle Corporation. All Rights Reserved. |
|