Oracle® Containers for J2EE Security Guide 10g (10.1.3.1.0) Part Number B28957-01 |
|
|
View PDF |
OC4J supports the Common Secure Interoperability Version 2 protocol (CSIv2), an Object Management Group (OMG) standard that can be used in conjunction with EJBs for a secure interoperable wire protocol that supports authorization and identity delegation.
CSIv2 specifies different conformance levels; OC4J complies with the EJB specification, which requires conformance level 0.
There are three files relevant to CSIv2 configuration:
internal-settings.xml
(server side)
ejb_sec.properties
(client side)
orion-ejb-jar.xml
This chapter is organized as follows:
CSIv2 Security Properties in internal-settings.xml (EJB Server)
CSIv2 Security Properties in ejb_sec.properties (EJB Client)
Specify server security properties for CSIv2 in the file internal-settings.xml
, using attribute values within <sep-property>
elements.
Table 19-1 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).
Table 19-1 EJB Server Security Properties
Property | Description |
---|---|
port |
IIOP port number (defaults to |
ssl |
A |
ssl-port |
IIOP/SSL port number (defaults to |
ssl-client-server-auth-port |
Port used for client and server authentication (defaults to |
keystore |
Name and path of the keystore (used only if |
keystore-password |
Password for keystore (used only if |
trusted-clients |
Comma-delimited list of hosts whose identity assertions can be trusted. Each entry in the list can be an IP address, a host name, a host name pattern (for example, |
truststore |
Name and path of the truststore. An absolute path is recommended. If you do not specify a truststore for a server, OC4J uses the keystore as the truststore (used only if |
truststore-password |
Password for truststore (used only if |
To use the CSIv2 protocol with OC4J, you must both set ssl
to true
and specify an IIOP/SSL port (ssl-port
). Note the following:
If you do not set ssl
to true
, CSIv2 is not enabled.
Setting ssl
to true
permits clients and servers to use CSIv2, but does not require them to communicate using SSL.
If you do not specify ssl-port
, then no CSIv2 component tag is created, even if you configure an <ior-security-config>
entity in orion-ejb-jar.xml
.
When IIOP/SSL is enabled on the server, OC4J listens on two different sockets—one for server authentication alone and one for server and client authentication. Specify the server authentication port number within the <sep-property>
element. OC4J adds 1 to this for the server and client authentication port number.
For SSL clients using server authentication alone, you can specify your choice of the following:
Truststore only
Both keystore and truststore
Neither
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 authentication must specify both a keystore and a truststore. The certificate from the keystore is used for client authentication.
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="true" /> <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>
Notes:
|
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*)>
Any client, whether running inside a server or not, has EJB security properties. Table 19-2 following lists the EJB client security properties controlled by the ejb_sec.properties
file. By default, OC4J searches for this file in the current directory when running as a client, or in ORACLE_HOME
/j2ee/home/config
when running in the server. You can specify the location of this file explicitly with the system property setting -Dejb_sec_properties_location=
pathname
.
Table 19-2 EJB Client Security Properties
Property | Description |
---|---|
oc4j.iiop.keyStoreLoc |
The path and name of the keystore. An absolute path is recommended. |
oc4j.iiop.keyStorePass |
The password for the keystore. |
oc4j.iiop.trustStoreLoc |
The path name and name of the truststore. An absolute path is recommended. |
oc4j.iiop.trustStorePass |
The password for the truststore. |
oc4j.iiop.enable.clientauth |
Whether the client supports client-side authentication. If this property is set to |
nameservice.useSSL |
Whether to use SSL when making the initial connection to the server. |
client.sendpassword |
Whether to send user name and password in clear form (unencrypted) in the service context when not using SSL. If this property is set to |
oc4j.iiop.trustedServers |
A list of servers that can be trusted to receive passwords sent in clear form. This has no effect if |
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 subject 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 DN from the client's certificate and then looks it up in the corresponding security provider; it does not perform password authentication.
Two types of trust relationships exist:
Clients trusting servers to transmit user names and passwords using non-SSL connections
Servers trusting clients to send identity assertions, which delegate an originating client's identity
Clients list trusted servers in the EJB property oc4j.iiop.trustedServers
. Servers list trusted clients in the trusted-client
property of the <sep-property>
element in internal-settings.xml
, discussed in "CSIv2 Security Properties in internal-settings.xml (EJB Server)" .
Conformance level 0 of the EJB standard defines two ways of handling trust relationships:
Presumed trust, in which the server presumes that the logical client is trustworthy, even if the logical client has not authenticated itself to the server, and even if the connection is not secure.
Authenticated trust, in which the target trusts the intermediate server based on authentication, either at the transport level or in the trusted-client
list or both.
OC4J supports both kinds of trust. Configure trust using the <ior-security-config>
element in orion-ejb-jar.xml
, discussed in the next section, "CSIv2 Security Properties in orion-ejb-jar.xml".
Notes:
|
This section discusses the CSIv2 security properties for an EJB. Configure the CSIv2 security policies of each individual bean in its orion-ejb-jar.xml
file. The CSIv2 security properties are specified within <ior-security-config>
elements. Each element contains a <transport-config>
subelement, an <as-context>
subelement, and a <sas-context>
subelement.
The DTD for the <ior-security-config>
element is as follows:
<!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) >
The rest of this section covers the following elements:
This element specifies the transport security level. Each subelement under <transport-config>
must be set to supported
, required
, or none
. The setting none
means the bean neither supports nor uses that feature; supported
means the bean permits the client to use the feature; required
means the bean insists that the client use the feature. The subelements 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? This element may be set to either supported
or none
; it cannot be set to required
.
<establish-trust-in-client>
: Does the client authenticate itself to the server?
Notes:
|
This element specifies the message-level authentication properties. Its subelements are:
<auth-method>
: Must be set to either username_password
or none
. If it is set to username_password
, beans use user names and passwords to authenticate the caller.
<realm>
: Must be set to default
in the current implementation.
<required>
: If this is 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 subelement, <caller-propagation>
, which can be set to supported
, required
, or none
, as follows:
If it is set to supported
, the bean accepts delegated identities from intermediate servers.
If it is set to required
, the bean requires all other beans to transmit delegated identities.
If it is set to none
, the bean does not support identity delegation.
The following example uses the <ior-security-config>
element and its subelements:
<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>