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. |
|