| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
The OC4J 10.1.3.1 implementation packages an alternative Java single sign-on solution that does not rely on additional required infrastructure like other Oracle Application Server single sign-on products. This Java SSO, based on the OracleAS JAAS Provider identity management framework discussed in Chapter 13, can be used across Web applications in any of the following deployment scenarios:
Web applications are deployed in the same application EAR file.
Web applications are deployed in different application EAR files in the same OC4J instance.
Web applications are deployed in different application EAR files in different OC4J instances, where the Web applications share a common security domain and cookie domain.
A single application EAR file, including Web applications, is deployed into multiple OC4J instances within an OC4J cluster.
This chapter documents OC4J Java SSO, covering the following topics:
Notes:
If you use any identity store other than the file-based provider or Oracle Internet Directory, you must define an administrative user account and administrative roles, grant the roles to the user, and grant necessary permissions to the roles, as discussed in "Creating the Administrative User and Roles and Granting RMI Permission".
This upgrades and replaces the functionality of the "Lightweight J2EE Single Sign-On" feature documented for Oracle Application Server 10g Release 2 (10.1.2). That feature is desupported.
This section provides an overview of Java SSO, including the following:
In Oracle Application Server, to use Oracle Single Sign-On you must have a separate Oracle Application Server installation with Oracle Identity Management, including Oracle Internet Directory, Oracle Single Sign-On, and Oracle Database. Alternatively, to use the Oracle Access Manager single sign-on solution, you must have a full Oracle Access Manager installation. These single sign-on solutions are closely coupled with the required infrastructure. While robust, neither may be viable for smaller deployment scenarios, and neither can be used with standalone OC4J by itself.
As an alternative, the OC4J 10.1.3.1 implementation supplies Java SSO, which is packaged with OC4J itself and decouples OC4J from whatever identity server you want to use. This allows applications deployed in the same OC4J instance or cluster to have a single point of authentication and the ability to share user identities.
OC4J Java SSO can be used with any security provider supported by OracleAS JAAS Provider (summarized in "Introducing the OracleAS JAAS Provider and Security Providers"). Furthermore, any login module (including custom ones) that conforms to certain requirements can be used in conjunction with Java SSO. In particular, the login modules RealmLoginModule, LDAPLoginModule, and DBTableOraDataSourceLoginModule provided with OC4J support the identity assertion feature of the identity management framework and can be used with Java SSO and partner applications. (An instance of IdentityCallback, discussed in "Oracle Callback Implementations", is used to determine the identity to assert.)
Notes:
Be aware of the following limitations in the 10.1.3.1 Java SSO implementation:There is no access control or authorization functionality. It is for authentication and identity assertion only.
It is limited to Web applications sharing a common cookie domain.
The UserManager interface (deprecated for general use anyway) is not supported.
Java SSO includes a dedicated Java SSO application (predeployed in OC4J) and an implementation of the OracleAS JAAS Provider identity management framework.
This section discusses the following:
There are three basic scenarios to consider in discussing how OC4J Java SSO works with a particular application:
A user with no identity token tries to access the application, in which case login is required. As discussed in Chapter 13, "Pluggable Identity Management Framework", an identity token corresponds to a user and user credentials. For Java SSO, the token is an HTTP cookie.
A user with an identity token tries to access the application, in which case the token must be validated and the identity asserted.
An authenticated user tries to access the application, where a subject and identity token are both available and no further authentication or assertion is required.
Typical interaction with Java SSO is as follows:
A client tries to access protected content (requests a protected URL) from an application, App1 for example.
App1 requires SSO authentication; the client is prompted for credentials by Java SSO.
The client provides credentials.
Java SSO delegates authentication to the security provider.
Upon successful authentication, the security subsystem establishes the identity.
The SSO provider (the Java SSO implementation of the identity management framework) encodes an identity token—the Java SSO cookie—corresponding to the authenticated user, and returns the cookie to the client.
The client presents the cookie to access App1.
App1 determines the client identity from the cookie and allows the client to access the protected content.
The client reuses the cookie to try to access protected content of another application, App2 for example.
App2 determines the client identity from the cookie and allows the client to access the protected content.
When using Java SSO, a user session is active until one of the following occurs:
The application calls the Java SSO logout API (discussed in "Java SSO Logout API").
The Java SSO cookie becomes invalid.
The set of applications that will share usage of Java SSO are referred to as partner applications. These may be customer applications, or may be Oracle Application Server console applications such as Application Server Control, Oracle BPEL Process Manager, or Oracle Web Services Manager. A partner application is one of the applications in a security domain that delegates authentication through Java SSO. In a security domain, multiple applications share common identity stores, algorithms, and keys used in the authentication and validation process.
Figure 14-1 following presents a flow chart for Java SSO logic.
The Java SSO application, javasso, is deployed in all OC4J instances as a built-in system application. The application consists of the login servlet SSOLogin and the logout servlet SSOLogout.
When you start OC4J, javasso is typically disabled (except in an Oracle Application Server "Basic Install"). An administrator can start javasso through Application Server Control.
Once javasso is enabled, attempts to access Java SSO partner applications result in a process such as the following, as depicted in Figure 14-2 below.
Note:
Assume
App1 and App2 below are partner applications configured to use Java SSO for single sign-on.A user, through the browser, attempts to access a protected URL for application App1.
There is a redirect to javasso (more specifically, the SSOLogin servlet) through the browser.
The App1 URL is passed to javasso.
Through javasso functionality, the user is prompted with the Java SSO login page.
The user supplies the user name and password.
Through javasso functionality, the user is authenticated according to information in the identity store. After the user is successfully authenticated, the SSOLogin servlet maps the authenticated identity to the Java SSO cookie (identity token), then uses a symmetric key cipher to sign and encrypt the contents of the cookie.
There is a redirect to App1 through the browser, and the secured cookie is sent back to the client.
The user accesses the content of App1.
The user attempts to access a protected URL for application App2, and is able to access the content of App2 without authentication.
Java SSO is an implementation of the identity management framework documented in Chapter 13, "Pluggable Identity Management Framework". The Java SSO implementation uses a cookie for credentials.
Java SSO is installed with OC4J and includes the following:
There is a cookie, ORA_OC4J_SSO, for user credentials.
A token collector implementation class, SSOCookieTokenCollector, collects credentials from a cookie (passed through the HTTP request), constructs a cookie identity token, and returns the cookie identity token to OC4J. Content of the token includes the user identity, issuing authority, token lifetime, and a digital signature to ensure content integrity.
A token asserter implementation class, SSOCookieTokenAsserter, asserts the user identity—receives the cookie token from OC4J, validates it, determines the identity in the cookie, and passes the asserted identity back to OC4J in an identity callback handler.
To decode the cookie token, the token asserter retrieves a shared key (shared between all partner applications and the Java SSO application) and decrypts the contents of the cookie. The token asserter validates the data by verifying the signature. (If the cookie has expired, an error is thrown, typically resulting in the user being redirected to the login page.)
Note:
In the Java SSO implementation, the cookie used as the identity token is a session cookie; it is not persistent.Of particular significance, consider these Java SSO deployment scenarios:
Single instance of OC4J
The javasso application, customer applications, and Application Server Control all run in the same OC4J instance.
SOA installation with two OC4J instances, using the file-based provider
The Oracle BPEL Process Manager (the Business Process Execution Language engine) and OWSM (Oracle Web Services Manager) run on the OC4J_SOA instance. The javasso application, customer applications, and Application Server Control run on the OC4J_Home instance.
The system-jazn-data.xml file (file-based provider) must be synchronized between the two instances, as discussed in "Considerations with the File-Based Provider and Two OC4J Instances".
SOA installation with two OC4J instances, using Oracle Internet Directory
The Oracle BPEL Process Manager and OWSM run on the OC4J_SOA instance. The javasso application, customer applications, and Application Server Control run on the OC4J_Home instance.
A single Oracle Internet Directory instance is used as the security provider.
High-availability installation with multiple OC4J instances, using Oracle Internet Directory
The javasso application and all customer applications are available on all instances.
A single Oracle Internet Directory instance is used as the security provider.
Notes:
Partner applications (either Oracle Application Server console applications or customer applications) can be split between OC4J instances however desired, but scenarios such as the above are typical.
Customers using Oracle Internet Directory within a full Oracle Identity Management environment would typically use Oracle Single Sign-On instead of Java SSO, but there may be situations where Java SSO with Oracle Internet Directory is useful.
Beyond standard configuration for a user's J2EE application, the following configuration steps are required. These are covered in detail in "Java SSO Setup and Configuration".
The javasso application must be started, through Application Server Control.
In any target OC4J instance, the jazn.xml file must have the correct property settings for Java SSO and its implementation of the identity management framework. You can set properties through Application Server Control, which can also generate the symmetric key. Settings are indicated in <property> subelements of the <jazn> element. Configuration includes the following (default settings may be adequate):
Java SSO login URL and logout URL
Symmetric key used to encrypt the cookie token
DNS domain to which the Java SSO cookie is restricted (required in advanced installations, across multiple OC4J instances and hosts)
(Be sure the cookie domain is set properly, as discussed in the troubleshooting section, "Returned to Java SSO Login Page Despite Correct Credentials".)
The partner applications using Java SSO must all be configured to use the same security provider and same identity store as the javasso application. (In particular, when using the file-based provider, use the same repository file. For a scenario with multiple OC4J instances, see "Considerations with the File-Based Provider and Two OC4J Instances".) By default, javasso is configured to use the file-based provider, but you can change this using the Application Server Control Console.
For partner applications that are customer applications, you can configure the security provider during deployment. For Application Server Control itself, there are special steps in Application Server Control Console to change the security provider. For other Oracle Application Server console applications that you want to include, if changes are necessary they can be handled similarly to changing the security provider for javasso.
Each partner application must be enabled to use Java SSO. This can also be configured through Application Server Control . Being enabled to use Java SSO is indicated by a setting of auth-method="CUSTOM_AUTH" in the <jazn-web-app> element, a subelement of <jazn> in orion-application.xml.
Note:
Java SSO supports any provider supported by OracleAS JAAS Provider.This section discusses localization and customization of the Java SSO login page and error pages.
The Java SSO login page and error pages shipped with OC4J support localization. Content displayed by these pages is localized according to the browser settings.
We do not directly support the use of a custom login page or custom error pages with Java SSO, but you can customize the deployed login.jsp, loginerror.jsp, and error.jsp files and do one of the following:
Replace the existing files in the deployment directory:
ORACLE_HOME/j2ee/home/applications/javasso/javasso-web/WEB-INF
Repackage and redeploy the javasso.ear file with the customized files.
This section discusses Java SSO configuration in OC4J, covering the following topics:
We recommend that you configure Java SSO and partner applications through Application Server Control, which is covered in the first section. The second and third sections show the configuration parameters and properties that are set as a result (and can also be set manually as necessary). The final section is for special considerations and scenarios.
In the Application Server Control Console, use the Java SSO Configuration page. You can navigate to this page as follows:
In an Oracle Application Server clustered environment, from the Cluster Topology page, choose Java SSO Configuration.
In an OC4J standalone environment:
From the OC4J Home page, select the Administration tab.
From the Administration page, under "Properties", go to the SSO Configuration task.
The rest of this section covers the following topics:
In an Oracle Application Server clustered environment, from the Cluster Topology page, you can start the javasso application for any OC4J instance (as necessary):
Under Members (which lists the application server and OC4J instances), choose the Expand All link to see all the applications under each instance.
Select the javasso application for the desired instance.
Choose Start.
In an OC4J standalone environment, you can start the javasso application as follows:
From the OC4J Home page, choose Applications.
From the Applications page, select the javasso application.
Choose Start.
From the Java SSO Configuration page, select the Instances and Properties tab to set Java SSO properties. This also enables you to generate a new symmetric key.
From the Instances and Properties page, you can specify the following:
The key type. Choose AES_128_CBC, AES_192_CBC, AES_256_CBC, or DES_EDE_CBC. This information is coded into the custom.sso.key.alias Java SSO property, discussed in "Java SSO Configuration Properties".
The URL for the Java SSO SSOLogin servlet (corresponding to the custom.sso.url.login property). If you have multiple hosts, use the fully qualified domain name.
The URL for the Java SSO SSOLogout servlet (corresponding to the custom.sso.url.logout property). If you have multiple hosts, use the fully qualified domain name.
The session timeout in seconds (corresponding to the custom.sso.session.timeout property). Note that this is a hard timeout, not an inactivity timeout. The session will timeout after this amount of time no matter what.
The number of login attempts to allow (corresponding to the custom.sso.login.attempts property).
If Java SSO has not yet been properly configured, use Configure Java SSO, after setting any of the above parameters as appropriate, to configure it. This will automatically generate a new symmetric key.
To reconfigure Java SSO after it has been properly configured, there is a checkbox to specify whether a new symmetric key should be generated when you apply the reconfiguration. You should generate a new key in either of the following circumstances:
If an error condition has arisen where different OC4J instances may be using different keys. All instances must use the same key.
If you want a new key just to be cautious from a security standpoint. (We recommend that you do this on a regular basis.)
Choose Apply (which appears in place of Configure Java SSO), after setting any of the above parameters as appropriate, to apply the reconfiguration and generate the key (as applicable).
Settings are reflected in <property> subelements under the <jazn> element in the jazn.xml file. In a cluster, these settings and the key apply across all OC4J instances.
Important:
When using the 10.1.3.1 patch set (as opposed to a fresh 10.1.3.1 installation), default jazn.xml settings shown in "Default Java SSO Property Settings for Single-Instance OC4J Installations" will not be present. Add these settings manually before configuring Java SSO.
By default, the jazn.xml file has a dummy value for the key (in the custom.sso.key.alias setting) until you configure Java SSO.
All applications configured to use the same Java SSO should share a single key. (This is a potential issue only in a scenario with multiple OC4J instances.)
You must restart OC4J instances for these changes to take effect. You will be notified and prompted to do so.
If you will be using Oracle Identity Management, make Java SSO settings after associating the OC4J instance with the Oracle Internet Directory instance. When you do the association, the <jazn> element configuration in the jazn.xml file of the OC4J home instance is rewritten and any previous settings are lost.
The javasso application that is used, and each partner application using Java SSO, must all be configured to use the same security provider. By default, javasso is configured to use the file-based provider.
To change the security provider for javasso in a given OC4J instance, go to the OC4J Home page for that instance in the Application Server Control Console. In a standalone environment, there is only one OC4J Home page. In an Oracle Application Server clustered environment, choose the desired OC4J instance in the Cluster Topology page.
From the OC4J Home page, select the Administration tab.
From the Administration page, under "Security", go to the Security Providers task.
From the Security Providers page, go to the Edit task for javasso.
From the Security Provider page for javasso, choose Change Security Provider.
Notes:
You must restart the application for a change in security provider to take effect.
Where there are multiple OC4J instances and not all javasso applications have the same security provider, there is a Change Security Provider option relating to the javasso application for each OC4J instance on the Java SSO Instances and Properties page in the Application Server Control Console. This simplifies the process of configuring the javasso application you want to use.
Each type of security provider necessitates its own set of configuration tasks, documented in the following locations:
As noted above, all partner applications and the javasso application must be configured to use the same security provider. For customer applications that are partner applications, configure the appropriate security provider during deployment. Each type of security provider necessitates its own set of configuration tasks, documented in the following locations:
"Configuring the File-Based Provider during Application Deployment"
"Specifying and Configuring a Custom Security Provider during Deployment"
"Specifying and Configuring an External LDAP Provider during Deployment"
If you want any Oracle Application Server console applications to share in using Java SSO (Application Server Control, for example), you must also ensure that the console applications use the same security provider.
For Application Server Control, you can change the security provider through the following steps:
In the OC4J Home page for the instance where Application Server Control is running, choose Administration.
In the Administration page, under "Security", go to the Security Providers task.
In the Security Providers page, choose Application Server Control Security.
In the initial Setup page, choose Security Provider.
In the Security Provider page, choose Change Security Provider.
In the Change Security Provider page, specify whether to use the system-jazn-data.xml file-based provider, an application-specific jazn-data.xml file-based provider, or Oracle Identity Management (if an Oracle Internet Directory instance had previously been associated with the OC4J instance, as described in "Associating Oracle Internet Directory with OC4J").
Choose OK. You must then restart Application Server Control for the change to take effect.
For other console applications, steps for changing the security provider would be similar to those for javasso in the preceding section, "Configure the Security Provider for the javasso Application". You must then restart the application for a change in security provider to take effect.
From the Java SSO Configuration page, select the Participating Applications tab to enable applications to use Java SSO.
From the Participating Applications page:
Select Java SSO Enabled for each desired application.
Choose Apply to enable them to use Java SSO.
This results in the setting auth-method="CUSTOM_AUTH" in the <jazn-web-app> element of the orion-application.xml file for each application.
Once you have started the javasso application and enabled an application to use Java SSO, invoking the application results in a login prompt through Java SSO.
Important:
If you will be using Oracle Identity Management as the security provider for an application, configure that before enabling the application for Java SSO. When you switch from the file-based provider to Oracle Identity Management through Application Server Control at any time for any partner application, the <jazn> element in orion-application.xml for the application is replaced with the following. Any previous setting to enable the application for Java SSO (the CUSTOM_AUTH setting) will be lost and must be redone.
<jazn provider="LDAP" />
You must restart OC4J instances for these changes to take effect. You will be notified and prompted to do so.
If you have multiple hosts, use the fully qualified domain name when invoking partner applications from your browser.
In general, we recommend that you configure Java SSO through Application Server Control, as discussed in preceding sections.
This section provides descriptions for all Java SSO configuration properties and shows the default settings (as applicable) upon OC4J installation.
Table 14-1 describes Java SSO properties whose settings would be reflected in the jazn.xml file, in <property> subelements of the <jazn> element.
Properties that are not supported through Application Server Control (as indicated by "n/a" in the table) must be set manually.
Table 14-1 Java SSO Properties
| Property | Description | Name in Application Server Control |
|---|---|---|
|
custom.sso.app.url.default |
The default URL for redirection from the |
n/a |
|
custom.sso.cookie.domain |
The Java SSO cookie is restricted to this DNS domain. By default, without a domain setting, the cookie is restricted to the host from which the (Be sure the cookie domain is set properly, as discussed in the troubleshooting section "Returned to Java SSO Login Page Despite Correct Credentials".) |
n/a |
|
custom.sso.cookie.path |
Path restriction for the cookie. Default: |
n/a |
|
custom.sso.cookie.secure |
If Default: |
n/a |
|
custom.sso.key.alias |
Stores the shared symmetric key used to sign the contents of the Java SSO cookie identity token. |
n/a |
|
custom.sso.login.attempts |
Number of login attempts allowed. Default: 3 |
Number of Login Attempts |
|
custom.sso.session.timeout |
Period of time (in seconds) for which the Java SSO cookie is valid. Note that this is a hard timeout, not an inactivity timeout. The session will timeout after this amount of time no matter what. Default: 7200 |
Session Timeout |
|
custom.sso.token.asserter.authtypes |
Java SSO authentication method. This is the method that will be used to authenticate end users once they are redirected to Java SSO. You can specify a standard J2EE Web application authentication method. Default: |
n/a |
|
custom.sso.url.login |
URL of the |
Java SSO Login URL |
|
custom.sso.url.logout |
URL of the |
Java SSO Logout URL |
|
realm.user.manager.lazy.initialization |
Optional. This property is used with SSO configured applications and enables the lazy initialization of their configured realm user managers. Valid values are When set to |
n/a |
|
jazn.policy.ignore.cs |
Optional. This property is used with SSO configured applications and enables the lazy initialization of their configured realm user managers. Valid values are When set to |
n/a |
Important:
If you associate an OC4J instance with an Oracle Internet Directory instance, the<jazn> element configuration in the jazn.xml file of the OC4J home instance is rewritten and any previous settings are lost.By default in an installation where there is a single OC4J instance, OC4J is set up to use Java SSO as the identity management framework implementation. This includes settings for Java SSO properties documented in the preceding section, "Java SSO Configuration Property Descriptions", and Java SSO settings for identity management framework properties documented in "Configuring Identity Management Framework Properties".
Here are the preconfigured settings in jazn.xml:
<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com">
<!-- properties to configure the 3rd party IDM framework -->
<property name="idm.authentication.name" value="JavaSSO" />
<property name="idm.token.asserter.class"
value="oracle.security.jazn.sso.SSOCookieTokenAsserter" />
<property name="idm.token.collector.class"
value="oracle.security.jazn.sso.SSOCookieTokenCollector" />
<property name="idm.token.type" value="HTTP_COOKIE" />
<property name="idm.token.collector.cookie.1" value="ORA_OC4J_SSO" />
<!-- properties for the out of the box Java SSO -->
<property name="custom.sso.url.login" value="/jsso/SSOLogin" />
<property name="custom.sso.url.logout" value="/jsso/SSOLogout" />
<property name="custom.sso.key.alias" value="ssoSymmetricKey" />
</jazn>
Important:
These settings do not exist by default in some scenarios, as noted in "General Considerations for Multiple OC4J Instances" and "Considerations When Using the 10.1.3.1 Patch over 10.1.3.0.0". In these cases, manually add the default configuration to jazn.xml before configuring Java SSO.
By default, there is a dummy value for the key in the custom.sso.key.alias setting (as shown above) until you configure Java SSO through Application Server Control, as discussed in "Set Java SSO Properties and Generate the Symmetric Key". Once you configure Java SSO, the setting will change to something like the following:
value="{AES-128}IdG4OPSqGPJ8hZFPn1W4Uw=="
Each partner application that is to use Java SSO must be configured to enable Java SSO. We recommend that you do this through Application Server Control, as discussed in "Enable Partner Applications to Use Java SSO".
Enabling a partner application to use Java SSO is indicated by the authentication method setting "CUSTOM_AUTH" in the <jazn-web-app> element of the orion-application.xml file, as in the following example:
<jazn provider="XML" ... > ... <jazn-web-app auth-method="CUSTOM_AUTH" /> ... </jazn>
This triggers usage of Java SSO and its implementation of the identity management framework according to configuration in jazn.xml.
Important:
If you will be using Oracle Identity Management as the security provider for an application, configure that before enabling the application for Java SSO. When you switch from the file-based provider to Oracle Identity Management through Application Server Control at any time for any partner application, the<jazn> element in orion-application.xml is replaced with the following. Any previous setting to enable the application for Java SSO (the CUSTOM_AUTH setting) will be lost and must be redone.
<jazn provider="LDAP" />
Notes:
Notice that because the OC4J default configuration specifies Java SSO as the identity management framework implementation, enabling a partner application to use the identity management framework (auth-method="CUSTOM_AUTH") enables it to use Java SSO.
The <jazn-web-app> element is also supported in the orion-web.xml file, as a subelement of <orion-web-app>, for a particular Web application. A setting there overrides the orion-application.xml setting for that Web application.
An authentication method setting in orion-application.xml (or orion-web.xml) overrides any authentication method setting in web.xml.
Preceding discussion covered general configuration for Java SSO, but this section covers the following special considerations:
Considerations with the File-Based Provider and Two OC4J Instances
Considerations When Using the 10.1.3.1 Patch over 10.1.3.0.0
This section discusses a use case where you want to employ Java SSO with the file-based provider for single sign-on access across two OC4J instances, such as in a SOA installation. The key issue is synchronizing user accounts and roles within two system-jazn-data.xml files across both OC4J instances.
Consider a use case where:
A customer has created OC4J instances OC4J_HOME and OC4J_SOA (such as through the installer or manually through createinstance).
They would like to activate Java SSO in OC4J_HOME and deploy SOA applications in OC4J_SOA.
They would like to use the file-based provider in both OC4J_HOME and OC4J_SOA.
By default, each OC4J instance is configured with its own file-based provider, the system-jazn-data.xml file. For Java SSO to work correctly across both instances, however, user accounts and user roles must be synchronized across the two system-jazn-data.xml files. Using OC4J group functionality, the following steps make this possible:
Create an OC4J group for Java SSO—JSSO_GROUP, for example. Refer to "OC4J Basic Group Features".
Start the Java SSO application in OC4J_HOME after making sure it is configured to use the file-based provider, system-jazn-data.xml, which is its default setting. (Note that the Java SSO application should be started in only one OC4J instance in this sample use case.)
Deploy the J2EE applications that are to use Java SSO to the OC4J_SOA instance; configure each application to use the file-based provider; and enable Java SSO for each application.
Add OC4J_HOME and OC4J_SOA as members of JSSO_GROUP. Again refer to "OC4J Basic Group Features".
For ongoing user and role administration for these applications, the customer would use the OC4J J2EEServerGroup MBean that corresponds to JSSO_GROUP, executing appropriate security provider MBean operations. This MBean will ensure synchronization of user accounts and roles across the JSSO_GROUP members. Refer to "Cluster MBean Browser Features and the J2EEServerGroup MBean".
Note:
You can achieve the same result by manually coordinating user configuration between thesystem-jazn-data.xml files on the two instances, although this may be more prone to error.See Also:
For additional information about OC4J group features, the topic "Group OC4J Instances Page" in the Application Server Control online help
For an installation type with multiple OC4J instances, the default configurations discussed in "Default Java SSO Property Settings for Single-Instance OC4J Installations" are not in place—the properties may be referenced in jazn.xml, but not set.
Any configuration for Java SSO (and related configuration for the identity management framework) must be duplicated across instances. The primary concern is Java SSO or related identity management framework properties in jazn.xml that are not set through Application Server Control, as well as system-jazn-data.xml settings (as applicable). Java SSO properties that are set through Application Server Control, as well as the shared Java SSO key, are already propagated to all OC4J instances through Application Server Control functionality.
Take the following steps, as appropriate:
Complete your Java SSO setup and configuration, as described under "Configuring Java SSO through Application Server Control". Remember that Java SSO properties set through Application Server Control apply across instances.
Ensure that any other relevant property settings in jazn.xml, such as Java SSO properties not supported by Application Server Control, or additional related identity management framework properties, are duplicated across OC4J instances. Generally speaking, the only option for such properties is to manually repeat the configuration in the jazn.xml file of each OC4J instance.
Use OC4J group functionality to configure system-jazn-data.xml across a group. (This may be for the file-based security provider, login module settings, or policy settings, for example.) OC4J groups are discussed in "OC4J Basic Group Features". Also, "Cluster MBean Browser Features and the J2EEServerGroup MBean" discusses how to coordinate system-jazn-data.xml user settings across OC4J instances. There are also operations for maintaining login module configuration across instances (for example, setLoginModule).
See Also:
For additional information about OC4J group features, the topic "Group OC4J Instances Page" in the Application Server Control online help
For an installation of the OC4J 10.1.3.1 patch over an existing 10.1.3.0.0 installation (as opposed to a fresh 10.1.3.1 installation), the default configurations discussed in "Default Java SSO Property Settings for Single-Instance OC4J Installations" are not in place—the properties are not referenced in jazn.xml.
Manually add the default configuration to jazn.xml, then complete the appropriate Java SSO configuration described under "Configuring Java SSO through Application Server Control".
Java SSO supplies the following utility class:
oracle.security.jazn.sso.util.JSSOUtil
In the OC4J 10.1.3.1 implementation, this class provides the following API:
See Also:
Oracle Containers for J2EE Security Java API Reference for Javadoc that includes the Java SSO APIs
The JSSOUtil utility class that comes with Java SSO provides a static logout() method, to be used as the last step in application session logout, once you have completed any application-specific logout preparations and processing:
logout(HttpServletResponse response, String targetURL)
Supply the HTTP response object that corresponds to the request being processed, and specify the URL where the application is to be redirected after logout. The application is first directed to the Java SSO SSOLogout servlet, which unsets the Java SSO cookie, and then to the specified target URL.
For example:
JSSOUtil.logout(response, "http://portal.acme.com");
This section summarizes the previously discussed key action items for using Java SSO.
For development, using Java SSO is mostly transparent, without special coding required. The one point of integration, which you can optionally use, is the logout API documented in the previous section, "Java SSO Logout API".
For configuration, use the following steps, described in detail in "Java SSO Setup and Configuration". All steps can be completed through Application Server Control.
Start the javasso application.
Configure Java SSO properties. (Settings are written into <property> elements under the <jazn> element in jazn.xml.)
Configure the javasso application to use the appropriate security provider.
Configure partner applications to use the same security provider as javasso. For customer applications, set the security provider during deployment. For any Oracle Application Server console applications (such as Application Server Control) that will share in Java SSO, you can change the security provider appropriately.
Enable each partner application to use Java SSO. (This results in the setting auth-method="CUSTOM_AUTH" in the application orion-application.xml file.) This is the only configuration step required to convert an existing application to be Java SSO-enabled. You can leave <login-config> settings in web.xml files unchanged (they are overridden).
Important:
If you have multiple hosts, use the fully qualified domain name when invoking partner applications from your browser.This section discusses the following issues you may encounter:
Page Not Found
If you receive a "Page Not Found" error when attempting to access a partner application that has been enabled for Java SSO, it may be that the javasso application is not running. You can test this by trying to access the SSOLogin servlet. You can go to the URL directly:
http://host:port/jsso/SSOLogin
Or you can choose Test Login URL from the Application Server Control page where you configure Java SSO properties.
If you are redirected to the host:port top-level page, then the test is successful.
Instructions for starting the javasso application are in "Start the javasso Application".
Returned to Java SSO Login Page Despite Correct Credentials
If you provide correct credentials to the Java SSO login page but keep getting returned to that page, consider the following possibilities:
You are attempting to access a partner application through localhost or an IP address, which you are not allowed to do.
You are attempting to access a partner application where the domain is not specified exactly as it is for the javasso application. For example, it would not work to access an application as http://sso/myapp/index.jsp when the Java SSO login URL set through Application Server Control (and corresponding to the custom.sso.url.login property) is set as http://sso.mydomain.com/jsso/SSOLogin.
The cookie domain setting (custom.sso.cookie.domain property) does not match the domain where you try to access a partner application. For example, it would not work to access an application at http://app.mydomain.com/myapp/index.jsp when the cookie domain is set to .sso.mydomain.com. It would work, however, if the cookie domain is set to .mydomain.com.
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|