Authorization Rules Tab Creating an Policy Domain for Use with Oracle Web Services Manager

16-66 Oracle Fusion Middleware Application Security Guide

5. Default Authenticator

: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:

a. Go to Security Realms, Default Realm Name, and click Providers.

b. Click Authentication, Click DefaultAuthenticator to see its configuration

page.

c. Click the Common tab and set the Control Flag to SUFFICIENT.

d. Click Save. 6. Reorder Providers:

a. Click Security Realms, Default Realm Name, Providers.

b. On the Summary page where providers are listed, click the Reorder button

c. On the Reorder Authentication Providers page, select a provider name and

use the arrows beside the list to order the providers as follows: OAM Identity Asserter REQUIRED OID Authenticator SUFFICIENT Default Authenticator SUFFICIENT d. Click OK to save your changes

7. Activate

Changes: In the Change Center, click Activate Changes 8. Reboot Oracle WebLogic Server. 9. Proceed as follows: ■ Successful: Go to Testing the Identity Asserter with Oracle Web Services Manager . ■ Not Successful: Confirm the all providers have the proper specifications for your environment, are in the proper order, and that oamAuthnProvider.jar is in the correct location as described in Installing Components and Files for Authentication Providers and OAM 10g on page 16-4.

16.6.4 Testing the Identity Asserter with Oracle Web Services Manager

To validate the use of the Oracle Access Manager Identity Asserter with Oracle Web Services Manager, you can access the Web service protected by the Identity Asserter and Oracle Web Services Manager policies. If access is granted, the implementation works. If not, see Troubleshooting Tips for OAM Provider Deployments on page 16-69.

16.7 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the containers user session with the user identifying header in OSSO Proxy-Remote-User or the user data in the Oracle Access Manager SSO session cookie ObSSOCookie. Configuring Single Sign-On Using Oracle Access Manager 10g 16-67 SSO Synchronization Filter SSO Sync Filter is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with containers user session. SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie JSESSIONID. Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter: ■ User identifying header in OSSO Proxy-Remote-User ■ User data in the Oracle Access Manager SSO session cookie ObSSOCookie The job of SSO Sync Filter is to make sure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the containers user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use. Notes: ■ Enabled and Active by Default : SSO Sync Filter fetches the user information from the configured tokens, gets the user from existing session if any, invalidates the session and redirects to the requested URL in case the CurrentSessionUser does not match the incoming SSO User. Otherwise, the request is simply passed through. If you have not configured the OSSO or Oracle Access Manager Assertion Providers in your domain, the filter disables automatically during WebLogic Server start-up. ■ Active for All URIs by Default : No changes are required in the application code. ■ Configured for the OSSO TokensHeader : Proxy-Remote-User, and performs a case insensitive match. ■ Configured for the Oracle Access Manager SSO TokensHeader : OAM_ REMOTE_USER and REMOTE_USER, and does a case insensitive match. ■ Global Logout : SSO Sync Filter is intended to provide the Single Logout Experience to the Oracle Fusion Middleware applications that use the OSSO or Oracle Access Manager Solutions. Is handled similarly to single sign-on. After global logout is performed, SSO filter reconciles the session when subsequent access to an application that has not cleaned up its session is made. Any application that use the OSSO or Oracle Access Manager Solutions is expected to invalidate its session before making a call to OSSO logout or Oracle Access Manager logout. For more information on OSSO logout, see Example 17–2, SSO Logout with Dynamic Directives on page 17-11. For details about Oracle Access Manager logout, see Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates on page 16-10.