Different agents require different logout implementation steps. Oracle recommends that logout for Oracle Access Manager 11g be handled in the manner described in this chapter.
This chapter includes the following sections:
Configuring Centralized Logout for 11g Webgate with OAM 11g Server
Configuring Centralized Logout for 10g Webgate with OAM 11g Servers
Configuring Centralized Logout for Oracle ADF-Coded Applications
Caution:
Oracle recommends using the logout mechanism provided by Oracle Access Manager, not custom logout scripts.Before you can perform tasks in this chapter:
The partner application must be deployed on the Web server where the agent is configured and registered with OAM 11g
One of the following agents, on any supported Web server and platform, must be running and provisioned with OAM 11g as follows:
OAM 11g Webgate with OAM 11g Server
IAMSuiteAgent with OAM 11g Server
OAM 10g Webgate with OAM 11g Server
OAM 10g Webgate with OAM 10g Server
OSSO Agent (mod_osso)
Policies must be configured to protect the resource in an OAM 11g application domain
Oracle Access Manager 11g provides centralized logout (also known as global log out) for user sessions. With OAM, centralized logout refers to the process of terminating an active user session.
Centralized logout means:
Applications must not provide their own logout page for use in an SSO environment.
Applications must make their logout links configurable with a value that points to the logout URL specified by the OAM Webgate Administrator.
Note:
Oracle strongly recommends that applications use the ADF Authentication servlet, which interfaces with OPSS where a domain-wide configuration parameter can be used to specify the logout URL. This way applications need not be modified or redeployed to change logout configuration.Table 15-1 describes the circumstances under which centralized logout occurs.
Table 15-1 Centralized Logout Circumstances
Explicitly |
The client state is invalidated and the session ends. If a new attempt is made to access the resource, the client must re-authenticate.
|
---|---|
Implicitly |
When no user activity occurs within the defined session timeout period, the user is logged out automatically and redirected back to the partner with a new session ID and a new prompt for credentials. This occurs if no lower-level authentication is configured for the resource. With OAM 11g, the user is not logged out if 10g Webgate simply encounters a logout URL unless the logout.html provides an explicit redirection to the Server logout. The OAM 11g Webgate redirects the user to the Server logout. |
When the logout URL is encountered and the cookie is removed (ObSSOcookie for 10g Webgates; OAMAuthnCookie for 11g Webgates). Webgate logs out the user and requires re-authentication.
Note:
Unlike partner applications, external applications (Yahoo! Mail, for example), do not delegate authentication to OAM and do not cede logout control to the OAM single sign-on server. It is the user's responsibility to log out of each of these applications.This section provides the following topics:
About Centralized Logout with OAM 10g Agents and OAM 11g Servers
About Centralized Logout with OSSO Agents (mod_OSSO) and OAM 11g
About Centralized Logout for Applications Using Oracle ADF Security
This section describes the sign-out processing that occurs with OAM 11g Webgates protecting applications.
Generally speaking, during centralized logout with OAM 11g Server the SSO Engine receives a user-session-exists request. The Session Management Engine looks up the user session and responds that the user session exists. The SSO engine sends a Clear User Session request. The Session management engine clears the token and session context. The SSO engine sends a User Session Cleared response.
Clearing the user token and the session context clears the server-side state, which includes clearing the OAM_ID cookie set on the server side. When the agent is notified, the agent clears the client-side state of the partner application. For more information, see "Configuring Centralized Logout for 11g Webgate with OAM 11g Server".
The following process overview outlines typical SSO Engine and Session Management Engine processing during centralized logout.
Logout is initiated when an application causes the invocation of the logout.html file configured for any registered OAM 10g Webgate.
Generally speaking, during centralized logout with OAM 10g Webgates the SSO Engine receives a user-session-exists request. The Session Management Engine looks up the user session and responds that the user session exists. The SSO engine sends a Clear User Session request. The Session management engine clears the token and session context. The SSO engine sends a User Session Cleared response.
Clearing the user token and the session context clears the server-side state, which includes clearing the OAM_ID cookie set on the server side. When the agent is notified, the agent clears the client-side state of the partner application. For more information, see "Configuring Centralized Logout for 10g Webgate with OAM 11g Servers".
The IAMSuiteAgent is a domain-wide agent that provides single sign-on functionality for the IDM Administration Console. The IAMSuiteAgent is installed and pre-configured as part of the Oracle Access Manager 11g Server installation and configuration.
For more information, see "Configuring Centralized Logout for the IAMSuiteAgent".
With OSSO Agents (mod_osso 10g), partner applications also cede logout control to the OAM single sign-on server. When the user logs out of one partner application, she is automatically logged out of all other partner applications.
Note:
No change is needed in the logout URL configuration of existing applications that use the OSSO Agent.Process overview: Centralized logout with mod_osso
Clicking Logout in a partner application takes the user to the page where logout occurs
When a user has signed off successfully, each of the applications listed on the centralized logout page has a check mark beside the application name.
A broken image beside an application name identifies an unsuccessful logout.
Once all of the application names activated in a session have a check mark, you can click Return to go to the application from which you initiated logout.
Delete the custom mod_osso agent cookies on logout.
Oracle Application Development Framework (Oracle ADF) security and the Oracle Platform Security Services (OPSS) comprise Oracle WebLogic Server's security framework. On the Oracle WebLogic Server, you can run a Web application that uses Oracle ADF security, integrates with Oracle Access Manager 11g SSO, and uses OPSS SSO for user authentication.
In this situation, users can terminate a single sign-on session and log out of all active partner applications simultaneously by logging out of whatever application they are working in.
For more information, see "Configuring Centralized Logout for ADF-Coded Applications with OAM 11g".
This section provides the following topics:
Several elements in the OAM 11g Webgate registration page enable centralized logout for OAM 11g Webgates. After registration, the ObAccessClient.xml file is populated with the information in Table 15-2.
Table 15-2 Logout Elements in OAM 11g Webgate Registration
Configuring 11g Webgates for logout against OAM 11g Servers requires a logoutCallbackUrl
. Centralized logout for 11g agents sets the cookie from "loggedout" to empty and expires the OAMAuthnCookie_<host:port>_<random number> cookie to explicitly clear it during logout, (rather than leaving behind an empty or logged out cookie).
OAM 11g Webgates differ only slightly from 10g Webgates, and match only the URI part of "logoutCallbackUrl"
.
The SSO Engine supports the central logout page on the OAM Server and:
Calls back to "logoutCallbackUrl" of 11g Webgates during logout
Lands on "end_url" (passed in as query parameter) after logout
The Webgate parameter "logoutCallbackUrl
" can be configured (as /oam_logout_success, for example). Oracle recommends using a URI format without host:port, in which case, the OAM Server dynamically constructs the full URL based on the host:port in original request and calls back on it.
This can also be a full URL format with a host:port, where OAM 11g server calls back directly without reconstructing callback URL.
The OAM Server sets the cookie from "loggedout" to empty and expires the cookie to explicitly clear it during logout, rather than leaving behind an empty or logged out cookie.
For details, see "Configuring Centralized Logout for 11g Webgates".
During OAM 11g Webgate registration, use the following procedure to configure logout with OAM 11g.
To configure centralized logout for 11g Webgates
Choose your method for registration:
When creating or editing an agent registration, include appropriate logout values for your environment (Table 15-2):
Note:
If theLogOutUrl
parameter is already configured for the 11g Webgate (with a value other than "/oamsso/logout.html"
), then ensure that "/oamsso/logout.html
" is also present as part of the LogOutUrl
parameter.Logout URL
Logout Callback URL
Logout Redirect URL
Logout Target URL
Finish your agent registration, as usual.
Perform steps in "Validating Global Sign-On and Centralized Logout".
The IAMSuiteAgent is pre-configured with the logout parameters needed to perform central logout against the OAM 11g Server. While similar to a 10g Webgate, the IAMSuiteAgent does not have a local logout.html page to be configured. Instead, the IAMSuiteAgent is delivered with a pre-deployed application oamsso_logout), that is used by the agent to perform the logout.
The logout functionality for the IAMSuiteAgent requires that the oamsso_logout application is deployed in the Server where the IAMSuiteAgent is used. The initial installation adds this application to AdminServer and to OAM Servers. However, you must update this application's Target servers to include all those that are using the IAMSuiteAgent.
To configure logout for the IAMSuiteAgent
Log in to the WebLogic Server Administration Console.
Navigate to Domain, Deployments, oamsso_logout, Targets.
Select all the Servers where the IAMSuiteAgent is enabled and where logout is performed. For example, oim_server, oaam_admin, oaam_server, and so on.
Click Save.
This section provides the following topics:
About Centralized Logout Processing for 10g Webgate with OAM 11g Server
About the Centralized Logout Script for OAM 10g Agents with OAM 11g Servers
Configuring Centralized Logout for 10g Webgates with OAM 11g
The following process overview outlines the OAM 11g centralized logout process that occurs when the application is deployed on the Web server for which the protecting OAM 10g Webgate is configured.
Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM agent (in this case, a 10g Webgate).
Process overview: Centralized logout for Webgate 10g with OAM 11g Server
The application causes invocation of the logout.html file configured for the OAM 10g Webgate.
The application might also pass end_url
as a query string to logout.html. The end_url parameter could either be a URI or a URL. For example:
/oamsso/logout.html?end_url=/welcome.html or /oamsso/logout.html?end_url=http://my.site.com/welcome.html
Webgate clears the ObSSOCookie for its domain and loads the logout.html script.
If the end_url
parameter does not include host:port, the logout.html script gets the host:port of the local server and constructs the end_url
parameter as a URL. For example:
http://serverhost:port/oam/server/logout?end_url=http://my.site.com/ welcome.html
Logic in logout.html redirect to the OAM Server. For example:
http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/ welcome.html
The OAM Server executes logout as follows:
Cleans up the session information associated with the user at the server side.
Validates the end_url
and sends a page with callback URLs to the user's browser.
Note:
The Logout Callback URL is specified in the expanded OAM Agent registration page, as described in "About Creating and Editing Webgate Registration".From the callback page, a new request is initiated to a specific URI on each Webgate. When this request reaches the specific Webgate in the specific domain, the ObSSOCookie for that domain is cleared.
The user is redirected to the end_url
in the logout script. However, if the end_url
parameter is not present, an appropriate message is sent by the OAM Server.
For more information, see "About the Centralized Logout Script for OAM 10g Agents with OAM 11g Servers".
With an OAM 10g Webgate, the logout.html script is required for both single- and multiple DNS-domain centralized logout processing. The logout.html activates JavaScripts that perform the actual logout.
Note:
OAM 11g Webgates do not use the logout.html script and instead require additional details in their Agent registration configuration, as described in "Configuring Centralized Logout for 11g Webgate with OAM 11g Server".Example 15-1 is a logout.html script that you can use as a template by editing certain lines for your own environment, which are described at the top of the script. For instance, SERVER_LOGOUTURL
must be changed. Additional information is provided after the example.
Example 15-1 logout.html Script
<html> <head> <script language="javascript" type="text/javascript"> /////////////////////////////////////////////////////////////////////////////// //Before using, you need to change the values of: //a. "oamserverhost" to point to the host where the OAM 11g Server is running. //b. "port" to point to the port where the OAM 11g Server is running. /////////////////////////////////////////////////////////////////////////////// var SERVER_LOGOUTURL = "http://oamserverhost:port/oam/server/logout"; /////////////////////////////////////////////////////////////////////////////// function handleLogout() { //get protocol used at the server (http/https) var webServerProtocol = window.location.protocol; //get server host:port var webServerHostPort = window.location.host; //get query string present in this URL var origQueryString = window.location.search.substring(1); var newQueryString = ""; //vars to parse the querystring var params = new Array(); var par = new Array(); var val; if (origQueryString != null && origQueryString != "") { params = origQueryString.split("&"); for (var i=0; i<params.length; i++) { if (i == 0) newQueryString = "?"; if (i > 0) newQueryString = newQueryString + "&"; par = params[i].split("="); //prepare a new query string, if the end_url value needs to be changed newQueryString = newQueryString + (par[0]); newQueryString = newQueryString + "="; val = par[1]; if ("end_url" == par[0]) { //check if val (value of end_url) begins with "/" or "%2F" (is it an URI?) if (val.substring(0,1) == "/" || val.substring(0,1) == "%") { //modify the query string now val = webServerProtocol + "//" + webServerHostPort + val; } } newQueryString = newQueryString + val; } } //redirect the user to this URL window.location.href = SERVER_LOGOUTURL + newQueryString; } </script> </head> <body onLoad="handleLogout();"> </body> </html>
Process overview: Logic in logout.html
Gets the host and port from the incoming request.
Gets the end_url
parameter from the query string.
If the end_url
parameter is not a URL, then the logout.html script constructs a URL using the host and port from task 1. See "Guidelines for the end_url parameter in logout.html".
Redirects to the OAM Server logout URL (SERVER_LOGOUTURL). For example: http://myoamserver/host:port/oam/server/logout.
Use the end_url
constructed in process 2 as the query string.
Preserve all other query string parameters in the query string
Guidelines for the end_url parameter in logout.html
The end_url
parameter can be either a URI or an URL.
If the end_url
query string is a URI, without host and port, then the logout.html must construct the URL by determining the host and port of the Web Server where logout.html is hosted. For example:
http://myoamserverhost:port/oam/server/logout?end_url=http://my
.site.com/welcome.html
If the end_url
parameter is a URL with the host and port, the logout.html script simply passes that on without reconstructing it.
Note:
An ADF application must pass theend_url
parameter indicating where to redirect the user after logout, as described in "Configuring Centralized Logout for Oracle ADF-Coded Applications":
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
Table 15-3 illustrates how a logout link in the logout.html file might be specified:
The following procedures describe how to configure centralized logout for 10g Webgates with OAM 11g.
Note:
Optional tasks or those required for only multiple DNS domain logout are identified and can be skipped unless needed.Chapter 27, "Managing OAM 10g Webgates with OAM 11g" includes a sample procedure that includes steps for deploying an application in a WebLogic Server domain.
Task overview: Configuring centralized logout for 10g Webgates
Create a default logout page (logout.html) and make it available on the Webgate installation directory:
Create and edit logout.html for the Webgate based on Example 15-1, "logout.html Script".
Store your logout.html script in the following directory path:
Webgate_install_dir/oamsso/logout.html
Note:
If the logout.html file is located elsewhere, ensure that the logout link is correctly specified in the agent registration to point to the correct location of the logout.html file.Proceed with following steps, as needed.
Confirm that the LogOutUrl
parameter is configured for each resource Webgate, as follows:
Note:
If theLogOutUrl
parameter has already been configured for the 10g Webgate with a value other than "/oamsso/logout.html", then ensure that "/oamsso/logout.html" is also present as part of the LogOutUrl
parameter.Confirm that the <callBackUri
> is the second value as part of 'logOutUrls'.
Confirm that the two values are separated by commas: "/oamsso/logout.html, <CallbackUri>".
Ensure that the logout.html (from Step 1) redirects the user to this central logout URI, "/oam/server/logout' on the OAM 11g Server.
Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout, as described in "Guidelines for the end_url parameter in logout.html".
Multiple DNS Domains: Perform the following steps if you have multiple DNS domains configured for SSO.
Note:
The Logout Callback URL can be unique for each Webgate; however, to construct the Callback URL for each Webgate, it is sufficient for the OAM Server to know the host and port of each Webgate from each domain. The file that the Logout Callback URL points to must differ from the logout.html script in the Webgate installation directory.Configure the <CallbackUri
> as the second value in the logOutUrls parameter on each resource Webgate.
<CallbackUri
> is the location on Webgate where the request must be sent to for clearing the obssocookie in that domain. The <CallbackUri> cannot be logout.html.
Ensure that a file physically exists on each Web server at the <CallbackUri
> location (usually, at the same location as logout.html).
For example, if you configure a file named logout.png in the same location as logout.html, then a <CallbackUri
> of logout.png should have the value:
/oamsso/logout.png
Check the OHS Web server configuration file, httpd.conf, on which the 10g Webgate is configured and if the following lines exist delete them.
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
The Oracle Access Manager SSO solution is available for applications that are coded to Oracle ADF standards and the OPSS SSO Framework. ADF-coded applications that are configured to perform logout with OAM 11g, redirect to the /oamsso/logout.html resource. The IAMSuiteAgent intercepts and processes the request, cleans up the session, redirects to the central logout (done by the OAM Server) and redirects back to the end_url.
See Also:
Oracle Fusion Middleware Application Security GuideNote:
For ADF applications, only one extra configuration step is needed (to configure the OAMSSOProvider for OPSS).Task overview: Protecting ADF-coded applications with OAM 11g
Protect the ADF-coded application using either an:
11g Webgate
10g Webgate
Perform the single extra configuration step for ADF-coded applications: configure the OAMSSOProvider as described in "Configuring Centralized Logout for ADF-Coded Applications with OAM 11g".
Perform logout configuration steps for your chosen Webgate version.
This section includes the following topics, which you can skip if you do not have applications that are coded to Oracle ADF standards and the OPSS SSO Framework:
About Centralized Logout Processing for Applications Coded to Oracle ADF Standards
Configuring Centralized Logout for ADF-Coded Applications with OAM 11g
ADF-coded applications refer to either applications that have been fully integrated with ADF or those that simply use ADF Authentication Servlet to integrate with OPSS.
In this case, logout is initiated when an ADF application causes the invocation of the logout URI. The following process overview outlines the OAM 11g centralized logout process for applications coded to Oracle ADF standards.
Process overview: Centralized logout for ADF applications with 10g Webgate
An ADF application causes the invocation of the following URI.
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
The end_url
parameter specifies the URI to which the application returns control following logout.
ADF invokes the configured OPSS SSO provider (OAM in this case) and delegates the logout functionality to the configured logout URI by redirecting the request to the logout URI. The end_url
value is passed as a query string to the logout URI. For example: /oamsso/logout.html?end_url=<end_uri>
.
The logout URI is invoked on the Webgate front-ending the application.
10g Webgate clears the ObSSOCookie for its domain and loads the logout.html script.
If the end_url
parameter does not include host:port, the logout.html script gets the host:port of the local server and constructs the end_url
parameter as a URL. For example:
http://serverhost:port/oam/server/logout?end_url=http://my.site.com/ welcome.html
Logic in logout.html redirect to the OAM Server. For example:
http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/ welcome.html
The OAM Server executes logout as follows:
Cleans up the session information associated with the user at the server side.
Validates the end_url
and sends a page with callback URLs to the user's browser.
Note:
The Logout Callback URL is specified in the expanded (not short) OAM Agent registration, as described in Table 15-2.From the callback page, a new request is initiated to a specific URI on each Webgate. When this request reaches the specific Webgate in the specific domain, the ObSSOCookie for that domain is cleared.
The user is redirected to the end_url
in the logout script. However, if the end_url
parameter is not present, an appropriate message is sent by the OAM Server.
The following procedure is similar to configuring logout for 10g Webgates, with specific step for ADF-coded applications. The ADF-coded application must send the end_url
value to identify where to redirect the user after logout processing. However, with ADF-coded applications, logout occurs when the application causes the following URI to be invoked:
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
Note:
The Applcore f/w could facilitate triggering of the above URL and the ADF application could leverage that.Some steps in this procedure require the WebLogic Scripting Tool (WLST): wlst.sh (Linux) or wlst.cmd (Windows), which you must invoke from the WLST_install_dir.
See Also:
To configure centralized logout for ADF-coded applications
Check with the Administrator to confirm the location of the logout.html script configured with the agent, which you need in following steps.
Configure OPSS for OAM as the SSO provider to update jps-config.xml for the WebLogic administration domain, as follows:
On the computer hosting the Oracle WebLogic Server and the Web application using Oracle ADF security, locate the Oracle JRF WLST script. For example:
cd $ORACLE_HOME/oracle_common/common/bin
Connect to the computer hosting the Oracle WebLogic Server, enter the administrator ID and password, and the host and port of the WebLogic AdminServer:
wls:/> /connect('admin_ID', 'admin_pw', 'hostname:port'
For example, the Oracle WebLogic Administration Server host could be localhost
using port 7001
. However, your environment might be different.
Check with the Administrator to confirm the location of the logout.html script configured with the agent.
In Step d, you must use the value provided by the Administrator. Here, logouturi
value is the URI of the logout script /logout.html. The value could either begin with "logout." (exceptions are logout.gif and logout.jpg) or it could be any other value configured by the Administrator.
Enter the loginuri for ADF authentication and the logouturi (location of the logout.html script configured with the agent); the host and port are not needed.
wls:/>addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Here, loginuri=/${app.context}/adfAuthentication; logouturival is the URI of the logout script /logout.html. The logouturl could either begin with "logout" (exceptions are logout.gif and logout.jpg) or it could be any other value configured by the Administrator.
Required: The ADF application must pass the end_url parameter indicating where to redirect the user after logout, as follows:
If the end_url
parameter does not include host:port, the logout.html script gets the host:port of the local server and constructs the end_url
parameter as a URL. For example:
http://serverhost:port/oam/server/logout?end_url=http://serverhost:port/ welcome.html
OAM 11g Webgate: Perform steps in "Configuring Centralized Logout for 11g Webgates".
OAM 10g Webgate: Perform steps in "Configuring Centralized Logout for 10g Webgates with OAM 11g".
See Also:
"Scenario: Identity Propagation with the OAM Token" for details about setting up providers for Oracle Access Manager 11g Identity Assertion.On user logout, some custom cookies set by OAM Server through authentication response settings might not get deleted. However, you can edit oam-config.xml to configure the OAM Server to delete custom cookies set during authentication when a user logs out of OAM. For instance, when integrating with Oracle E-Business Suite, the ORASSO_AUTH_HINT cookie is set by the application and should be included in the CookieNames
list (or the UCM cookie, for example).
Syntax (beneath PluginClass" Type=
...):
<Setting Name="CookieDelMap" Type="htf:map"> <Setting Name="CookieNames" Type="xsd:string">COOKIE_NAME</Setting> </Setting>
The following procedure guides as you edit the CookieDelMap element and add CookieNames as a single value or a comma-separated list of custom cookies to delete when a user logs out. This procedure also explains how to increment the oam-config.xml file version to propagate your change to all managed servers without restarting.
Caution:
Work carefully. In general, Oracle recommends that you do not edit the oam-config.xml file. This, however, is a rare exception.To delete custom mod_osso cookies on logout
Back up DOMAIN_HOME/config/fmwconfig/oam-config.xml.
In oam-config.xml, add (or edit) the CookieDelMap
element and CookieNames
. For example:
<Setting Name="ResponsePluginSetting" Type="htf:map">
<Setting Name="PluginClass" Type=... </Settings>
<Setting Name="CookieDelMap" Type="htf:map">
<Setting Name="CookieNames" Type="xsd:string">ORASSO_AUTH_HINT
</Setting>
</Setting>
</Setting>
Configuration Version: Increment the Version xsd:integer
as shown in the next to last line of this example (existing value (25, here) + 1):
Example:
<Setting Name="Version" Type="xsd:integer">
<Setting xmlns="http://www.w3.org/2001/XMLSchema"
Name="NGAMConfiguration" Type="htf:map:>
<Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
<Setting Name="Version" Type="xsd:integer">25</Setting>
</Setting>
Save the file.
This section provides the following topics:
Use the following procedure to observe single sign-on global login.
Agents and Servers must be registered with OAM 11g and running
Resources and policies controlling SSO must be defined within OAM 11g application domains
From a browser, enter the URL to a protected resource and sign in using proper credentials.
Enter the URL to another protected resource and confirm that you are not asked to re-authenticate.
Use the following procedure to observe single sign-on global login with different applications and agents that have the same authentication level.
For example, suppose you have:
OSSO Partner at http://
host1.example.com:7777/private/index.html
protected using mod_osso
Webgate Partner at http://
host2.example.com:8888/mydomain/finance/index.html
protected using OAM Agent
Within the same browser session, you can access all applications protected by either agent with only a single sign in.
Agents and Servers must be registered with OAM 11g and running
Resources and policies must be defined within OAM 11g application domains
Both partners must be protected at the same authentication level
Single sign-on must be configured as described in this chapter
To observe global sign-on with mixed agent types
OSSO Agent Protected Application:
From a browser, enter the URL of the OSSO-protected resource
Confirm that the login page appears and sign in using proper credentials.
Confirm that the protected resource is served.
Remain in the same browser session and proceed to Step 2.
Same Browser Session, OAM Agent Protected Application:
In the same browser session as Step 1, enter the URL of the OAM Agent-protected resource.
Confirm that the protected resource is served and that no login page appears.
Log out of the browser session.
Fresh Browser Session, OAM Agent Protected Application:
In a fresh browser session, enter the URL of the OAM-protected resource.
Confirm that the login page appears and sign in using proper credentials.
Confirm that the protected resource is served.
Remain in the same browser session and proceed to Step 5.
Same Browser Session, OSSO Agent Protected Application:
In the same browser session as Step 4, enter the URL of the OSSO Agent-protected resource.
Confirm that the protected resource is served and that no login page appears.
Use the following procedure to observe centralized logout:
With OAM Agents, the logout URL redirects to the server and cookies are cleared and invalidated so that a subsequent request cannot locate the cookie.
With mod_osso, each agent destroys its own cookies. The logout URL redirects to the global logout page on the server and each partner sends cookies to the server.
Agents must be registered and running
Resources must be protected by OAM 11g application domains
Single sign-on must be configured with authentication and authorization policies and responses in OAM 11g application domains
Single Application:
From a browser, enter the URL of the protected resource.
Confirm that the login page appears and sign in using proper credentials.
Confirm that the protected resource is served.
Open a new browser tab or window and access the same resource to confirm that the second attempt does not require another login.
Logout from one tab.
Access the resource again to confirm that a login page appears.
Two Applications:
From a browser, enter the URL of the protected resource.
Confirm that the login page appears and sign in using proper credentials.
In a new tab or window, access another protected application and confirm that the second application does not require another login.
Log out of the first application.
Access the second application and confirm that the login page appears.