Reassociating the Credential and Policy Store Using WLST

Configuring Single Sign-on 30-3 OAM consists of the following components: ■ Access Server - a standalone server that provides authentication, authorization, and auditing services for Access Gates. There is one access server set up on OAM. This is done as part of the OAM install itself. ■ WebGate - an out-of-the-box plugin that intercepts Web resource HTTP requests and forwards them to the Access Server for authentication and authorization. ■ Identity Assertion Provider IAP - a type of security provider that asserts the identity of the user based on header information that is set by perimeter authentication. The OAM integration provides an OAM ID Asserter that can be configured as the OAM IAP. The OAM ID Asserter can be used for authentication or for identity assertion. For OAM SSO integration, the OAM ID Asserter should be configured as an Identity Assertion Provider IAP by selecting obSSOCookie under Active Types in the providers Common settings. OAM Single Sign-on Process Flow Figure 30–2 shows the single sign-on process flow for OAM. Figure 30–2 OAM Single Sign-on Process Flow SSO Log-in Processing with OAM Agents 1. The user requests a resource. 2. The WebGate forwards the request to OAM for policy evaluation. 3. OAM: 30-4 Oracle Fusion Middleware Administrators Guide for Oracle WebCenter ■ Checks for the existence of an SSO cookie. ■ Checks policies to determine if the resource protected and if so, how? 4. The OAM server logs and returns decisions. 5. WebGate responds as follows: ■ Unprotected resource: resource is served to the user. ■ Protected resource: – Request is redirected to the credential collector – The login form is served based on the authentication policy – Authentication processing begins 6. User sends credentials. 7. OAM verifies credentials. 8. OAM starts the session and creates the following host-based cookies: ■ One per partner: OAMAuthnCookie set by 11g WebGates ObSSOCookie set by 10g WebGate using the authentication token received from the OAM server after successful authentication. Note: A valid cookie is required for a session. ■ One for OAM Server: OAM_ID 9. OAM logs Success or Failure. 10. OAM Credential collector redirects to WebGate and authorization processing begins. 11. WebGate prompts OAM to look up policies, compare them to the users identity, and determine the users level of authorization. 12. OAM logs policy decision and checks the session cookie. 13. OAM Server evaluates authorization policies and cache the result. 14. OAM Server logs and returns decisions 15. WebGate responds as follows: ■ If the authorization policy allows access, the request get redirected to mod_wl which in turn redirects the request to the WLS server where the WebCenter Spaces application is running, and from where desired content or applications are served to the user, as shown below: WebGate - mod_wl - Spaces [, Discussion, .. etc] -- Content is server to the authenticated user ■ If the authorization policy denies access, the user is redirected to another URL determined by the administrator.

30.2.2 Roadmap to Configuring OAM

The flow chart Figure 30–3 and table Table 30–1 in this section provide an overview of the prerequisites and tasks required to configure single sign-on for WebCenter using OAM.