This chapter describes Access Manager single logout (also known as global logout) for sessions involving 11g Webgates. With Access Manager, single logout refers to the process of terminating an active session. Oracle recommends using the logout mechanism provided by Access Manager in the manner described in this chapter (not custom logout scripts).
This chapter provides the following sections:
See Also:
Different agents require different logout implementation steps described as follows:10g Webgate logout Chapter 23
OSSO Agent (mod_osso) logout Chapter 22
Before you can perform tasks in this chapter:
The application must be deployed on the Web server where the agent is configured and registered with Access Manager
One OAM Agent, on any supported Web server and platform, must be running and registered with Access Manager 11g (Chapter 14)
Policies must be configured to protect the resource in an Access Manager 11g Application Domain (Chapter 18)
Unless explicitly stated, information in this chapter applies to OAM 11g Webgate Agents using the default embedded credential collector (ECC).
This section provides the following topics:
Access Manager provides centralized logout (also known as global log out) for sessions. Centralized logout refers to the process of terminating an active session, which means that:
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 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.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.
Table 20-1 describes the circumstances under which centralized logout occurs. When the logout URL is encountered and the cookie is removed (OAMAuthnCookie for 11g Webgates; ObSSOcookie for 10g Webgates). Webgate logs out the user and requires user re-authentication.
Table 20-1 Centralized Logout Circumstances
| Circumstance | Description |
|---|---|
|
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 Access Manager, 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 Webgate redirects the user to the Server logout. |
Generally speaking, during centralized logout, the SSO Engine receives a user-session-exists request. The Session Management Engine looks up the session and responds with the-session-exists response. The SSO engine sends a Clear Session request. The Session management engine clears the token and session context. The SSO engine then sends a 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 application.
Configuring 11g Webgates for logout against OAM Servers requires a Logout Callback URL (Table 14-3). Centralized logout for 11g agents sets the cookie from loggedout to empty and expires OAMAuthnCookie_<host:port>_<random number> to explicitly clear it during logout, (rather than leaving behind an empty or logged out cookie).
11g Webgates differ only slightly from 10g Webgates, and match only the URI part of Logout Callback URL.
The SSO Engine supports the central logout page on the OAM Server and:
Calls back to Logout Callback URL of 11g Webgates during logout
The Webgate parameter Logout Callback URL can be configured using a URI format (recommended), without host:port. OAM Server dynamically constructs the full URL based on the host:port in the original request and calls back on it. This can also be a full URL format with a host:port, where OAM Server calls back directly without reconstructing callback URL.
Lands on end_url (passed in as query parameter) after logout
Several elements in the 11g Webgate registration page enable centralized logout for 11g Webgates. After registration, the ObAccessClient.xml file is populated with the information in Table 20-2.
Table 20-2 Logout Details After Registration (ObAccessClient.xml)
| Element | Description |
|---|---|
|
Logout URL 10g and 11g Webgates |
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 Access Manager.
Default = [] (not set) Note: This is the standard 10g Webgate configuration parameter used to trigger initial logout through a customized local logout page as described in "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers". |
|
Additional Logout for 11g Webgate Only |
For 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 a customized local logout page. |
|
Logout Callback URL |
The URL to Default = /oam_logout_success This can also be a full URL format with a host:port, where OAM 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 ( Note: In the remote registration template this parameter is named logoutCallbackUrl (Table 14-10). Other Oracle Access Management services support the central logout page on the server. The end_url relies on the target URL query parameter passed from OPSS integrated applications. See Also: "Configuring Centralized Logout for Oracle ADF-Coded 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 Access Manager.
|
|
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.
|
This section provides the following topics:
Configuring Centralized Logout for 11g Webgates When the ECC is Used
Configuring Logout When Using Detached Credential Collector-Enabled Webgate
See Also:
During 11g Resource Webgate registration or editing, you configure the logout parameters as described here.
Note:
If theLogOutUrl parameter is already configured for the 11g Webgate (with a value other than /oamsso/logout.html), then ensure that is also present as part of the LogOutUrl parameter.To configure centralized logout for 11g Webgates
Choose your method for registration described in Chapter 14, "Registering and Managing OAM 11g Agents"
When creating or editing an agent registration, include appropriate logout values for your environment (Table 20-2):
Logout URL
Logout Callback URL
Logout Redirect URL
Logout Target URL
Finish and save your agent registration, as usual.
Multiple DNS Domains: Perform the following steps if you have multiple DNS domains configured for Access Manager 11g SSO.
Note:
TheLogout Callback URL can be unique for each Webgate; however, to construct the Logout 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 Logout Callback URL as the second value in the logOutUrls parameter on each resource Webgate.
Logout Callback URL is the location on Webgate that the request must be sent to, for clearing the SSO Cookie in that domain. The Logout Callback URL cannot be logout.html.
Ensure that a file physically exists on each Web server at the Logout Callback URL 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 the Logout Callback URL of logout.png would be:
/oamsso/logout.png
Perform steps in "Validating Global Sign-On and Centralized Logout".
When the DCC receives a logout request from the Agent, the DCC:
Decrypts the logout request, if needed
Retrieves the end_url, constructs the full URL with the Agent's host:port if needed
Clears the DCC cookie (DCCCtxCookie)
Sends the logout request across the back channel to terminate the session
Logout Callback URLLogout Callback URLsGets a logout page containing links to all visited agent from OAM Sever (which has this information), or get only a list of the visited from OAM Sever to construct a logout page locally, and redirect user to this page on DCC.
Returns to the end_url after logout completes
To configure logout for Resource Webgates separate from DCC
Confirm that the Perl scripts for DCC logout include the actual location of the Perl executable on the Webgate host $WEBGATE_HOME/oamsso-bin/*pl.
Resource Webgate: Modify the Logout Redirect URL to point to DCC's logout.pl:
Find the Resource Webgate Registration: See "Searching for an OAM Agent Registration".
Modify the Logout Redirect URL to point to the DCC's logout.pl. For example:
http://DCCWGhost:port/oamsso-bin/logout.pl
Note:
The DCC ignores theLogout Redirect URL parameter in the Webgate registration page. However, if the Resource Webgate Logout Redirect URL is anything other than logout.*, then that URL must be defined in DCC Logout URLs. See Table 17-28, "Specifying Credential Collectors and Related Forms for Authentication"Perform steps in "Validating Global Sign-On and Centralized Logout".
This section provides the following topics:
Use the following procedure to observe single sign-on global login.
Agents and Servers must be registered with Access Manager and running
Resources and policies controlling SSO must be defined within Access Manager Application Domains
From a browser, enter the URL to a protected resource.
On the login page, sign in using proper credentials.
Verify that the resource is presented; do not log out.
In the same browser window, enter the URL to another protected resource and confirm that the resource is presented without having 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 Access Manager and running
Resources and policies must be defined within Access Manager 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 Access Manager Application Domains
Single sign-on must be configured with authentication and authorization policies and responses in Access Manager 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.