Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
11g Release 1 (11.1.1)

Part Number E15478-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

15 Configuring Centralized Logout for OAM 11g

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:

Caution:

Oracle recommends using the logout mechanism provided by Oracle Access Manager, not custom logout scripts.

Prerequisites

Before you can perform tasks in this chapter:

Introduction to OAM 11g Centralized Logout

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:

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.

  • When the user logs out.

  • When the administrator terminates the session

  • When the session is terminated based on changes on the identity side

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 11g Agents and Servers

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

About Centralized Logout with OAM 10g Agents and OAM 11g Servers

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

About Centralized Logout with the IAMSuiteAgent

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

About Centralized Logout with OSSO Agents (mod_OSSO) and OAM 11g

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

  1. Clicking Logout in a partner application takes the user to the page where logout occurs

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

  3. A broken image beside an application name identifies an unsuccessful logout.

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

  5. Delete the custom mod_osso agent cookies on logout.

About Centralized Logout for Applications Using Oracle ADF Security

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

Configuring Centralized Logout for 11g Webgate with OAM 11g Server

This section provides the following topics:

About Configuring Centralized Logout for 11g Webgates

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

Element Description

Logout URL

The Logout URL triggers the logout handler, which removes the cookie (ObSSOCookie for 10g Webgates; OAMAuthnCookie for 11g Webgates) and requires the user to re-authenticate the next time he accesses a resource protected by Oracle Access Manager.

  • If there is a match, the Webgate logout handler is triggered.

  • If Logout URL is not configured the request URL is checked for "logout." and, if found (except "logout.gif" and "logout.jpg"), also triggers the logout handler

Default = [] (not set)

Note: This is the standard OAM 10g Webgate configuration parameter used to trigger initial logout.

Additional Logout for 11g Webgates Only

For OAM 11g Webgate single sign-off behavior, the following elements and values automate the redirect to a central logout URL, callback URL, and end URL. This replaces 10g Webgate single sign-off only through customized local logout page.

Logout Callback URL

The URL to oam_logout_success, which clears cookies during the call back. This can be a URI format without host:port (recommended), where the OAM Server calls back on the host:port of the original resource request. For example:

Default = /oam_logout_success

This can also be a full URL format with a host:port, where OAM 11g server calls back directly without reconstructing callback URL

When the request URL matches the Logout Callback URL, Webgate clear its cookies and streams an image .gif in the response. This is similar to OSSO agent behavior.

When Webgate redirects to the server logout page, it records an "end" URL as a query parameter (end_url=http://host:port/..."), which becomes the landing page that the OAM 11g Server redirects back to after logout.

Other OAM 11g services support the central logout page on the server. The end_url relies on the target URL query parameter passed from OPSS integrated applications.

Logout Redirect URL

This parameter is automatically populated after agent registration completes.By default, this is based on the OAM Server host name with a default port of 14200. For example:

Default = http://OAMServer_host:14200/oam/server/logout

The Logout URL triggers the logout handler, which removes the OAMAuthnCookie_<host:port>_<random number> and requires the user to re-authenticate the next time he accesses a resource protected by Oracle Access Manager.

  • When Webgate logout handler is triggered, it redirects to the central logout page specified by the Logout Redirect URL parameter if it is configured.

  • It is unlikely that the Logout Redirect URL is not configured because this is populated after agent registration., 10g behavior is triggered: serve the local logout page instead of redirecting to another. The local logout page can have a customized script to redirect to the central logout page and can clear additional 3rd party cookies if desired.

Logout Target URL

The value for this is name for the query parameter that the OPSS applications passes to Webgate during logout. This query parameter specifies the target URL of the landing page after logout.

Default: end_url

Note: The end_url value is configured using param.logout.targeturl in jps-config.xml.

  • If Logout Target URL is configured, Webgate searches for the value passed in the logout request's query parameter and passes it as end_url query parameter in the redirect URL to OAM Server.

  • If Logout Target URL is not configured, Webgate searches for the default name "end_url" and passes that end_url query parameter along.


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

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

  1. Choose your method for registration:

  2. When creating or editing an agent registration, include appropriate logout values for your environment (Table 15-2):

    Note:

    If the LogOutUrl 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

  3. Finish your agent registration, as usual.

  4. Perform steps in "Validating Global Sign-On and Centralized Logout".

Configuring Centralized Logout for the IAMSuiteAgent

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

  1. Log in to the WebLogic Server Administration Console.

  2. Navigate to Domain, Deployments, oamsso_logout, Targets.

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

  4. Click Save.

Configuring Centralized Logout for 10g Webgate with OAM 11g Servers

This section provides the following topics:

About Centralized Logout Processing for 10g Webgate with OAM 11g Server

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

  1. 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
    
  2. Webgate clears the ObSSOCookie for its domain and loads the logout.html script.

  3. 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
    
  4. 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
    
  5. The OAM Server executes logout as follows:

    1. Cleans up the session information associated with the user at the server side.

    2. 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".
    3. 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.

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

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

  1. Gets the host and port from the incoming request.

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

  3. 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 the end_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:

Table 15-3 Sample end_url Parameter Specifications

As a ... Sample end_url Value

URI

/oamsso/logout.html?end_url=<someUri>

For example:

/oamsso/logout.html?end_url=/welcome.html

URL

/oamsso/logout.html?end_url=<someUrl>

For example:

/oamsso/logout.html?end_url=http://my.site.com/welcome.html

Configuring Centralized Logout for 10g Webgates with OAM 11g

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

  1. Create a default logout page (logout.html) and make it available on the Webgate installation directory:

    1. Create and edit logout.html for the Webgate based on Example 15-1, "logout.html Script".

    2. 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.
    3. Proceed with following steps, as needed.

  2. Confirm that the LogOutUrl parameter is configured for each resource Webgate, as follows:

    Note:

    If the LogOutUrl 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 LogOutUrlparameter.
    1. Confirm that the <callBackUri> is the second value as part of 'logOutUrls'.

    2. Confirm that the two values are separated by commas: "/oamsso/logout.html, <CallbackUri>".

  3. Ensure that the logout.html (from Step 1) redirects the user to this central logout URI, "/oam/server/logout' on the OAM 11g Server.

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

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

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

Configuring Centralized Logout for Oracle ADF-Coded Applications

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 Guide

Note:

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

  1. Protect the ADF-coded application using either an:

    • 11g Webgate

    • 10g Webgate

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

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

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

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

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

  3. The logout URI is invoked on the Webgate front-ending the application.

  4. 10g Webgate clears the ObSSOCookie for its domain and loads the logout.html script.

  5. 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
    
  6. 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
    
  7. The OAM Server executes logout as follows:

    1. Cleans up the session information associated with the user at the server side.

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

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

Configuring Centralized Logout for ADF-Coded Applications with OAM 11g

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.

To configure centralized logout for ADF-coded applications

  1. Check with the Administrator to confirm the location of the logout.html script configured with the agent, which you need in following steps.

  2. Configure OPSS for OAM as the SSO provider to update jps-config.xml for the WebLogic administration domain, as follows:

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

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

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

  3. 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
    
  4. OAM 11g Webgate: Perform steps in "Configuring Centralized Logout for 11g Webgates".

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

Removing Custom mod_osso Cookies on Logout

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

  1. Back up DOMAIN_HOME/config/fmwconfig/oam-config.xml.

  2. 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>
    
  3. 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>      
    
  4. Save the file.

Validating Global Sign-On and Centralized Logout

This section provides the following topics:

Confirming Global Sign-On

Use the following procedure to observe single sign-on global login.

Prerequisites

  • Agents and Servers must be registered with OAM 11g and running

  • Resources and policies controlling SSO must be defined within OAM 11g application domains

To observe global sign-on

  1. From a browser, enter the URL to a protected resource and sign in using proper credentials.

  2. Enter the URL to another protected resource and confirm that you are not asked to re-authenticate.

Validating Global Sign-On with Mixed Agent Types

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.

Prerequisites

  • 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

  1. OSSO Agent Protected Application:

    1. From a browser, enter the URL of the OSSO-protected resource

    2. Confirm that the login page appears and sign in using proper credentials.

    3. Confirm that the protected resource is served.

    4. Remain in the same browser session and proceed to Step 2.

  2. Same Browser Session, OAM Agent Protected Application:

    1. In the same browser session as Step 1, enter the URL of the OAM Agent-protected resource.

    2. Confirm that the protected resource is served and that no login page appears.

  3. Log out of the browser session.

  4. Fresh Browser Session, OAM Agent Protected Application:

    1. In a fresh browser session, enter the URL of the OAM-protected resource.

    2. Confirm that the login page appears and sign in using proper credentials.

    3. Confirm that the protected resource is served.

    4. Remain in the same browser session and proceed to Step 5.

  5. Same Browser Session, OSSO Agent Protected Application:

    1. In the same browser session as Step 4, enter the URL of the OSSO Agent-protected resource.

    2. Confirm that the protected resource is served and that no login page appears.

Observing Centralized Logout

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.

Prerequisites

  • 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

To observe centralized logout

  1. Single Application:

    1. From a browser, enter the URL of the protected resource.

    2. Confirm that the login page appears and sign in using proper credentials.

    3. Confirm that the protected resource is served.

    4. Open a new browser tab or window and access the same resource to confirm that the second attempt does not require another login.

    5. Logout from one tab.

    6. Access the resource again to confirm that a login page appears.

  2. Two Applications:

    1. From a browser, enter the URL of the protected resource.

    2. Confirm that the login page appears and sign in using proper credentials.

    3. In a new tab or window, access another protected application and confirm that the second application does not require another login.

    4. Log out of the first application.

    5. Access the second application and confirm that the login page appears.