9 Configuring Single Sign-On in Oracle Fusion Middleware

9.2.4.1 Applications Using Oracle Access Manager for the First TIme

If your application is to use Oracle Access Manager Authentication Provider for the first time, proceed based on the functionality that you want to use:

• Identity Asserter for Single Sign-On: The Web-only applications implementation handles nearly all SSO use cases. See "Installing the Authentication Provider with Oracle Access Manager 11g".

  Oracle Web Services Manager-Protected Web Services: These require the AccessGate provided with the Identity Asserter to interact with the OAM Server. See "Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g".

• Authenticator: No single sign-on is provided. The Authenticator requests credentials from the user based on the authentication method specified in the application configuration file, web.xml. See "Configuring the Authenticator for Oracle Access Manager 11g".

9.2.4.2 Applications Migrating from Oracle Application Server to Oracle WebLogic Server

If your application has been deployed on the old Oracle Application Server (OC4J), you can perform a few steps to make the application use the Authentication provider with Oracle WebLogic Server, proceed as follows:

• Remove all OC4J-specific settings from the application configuration

• Identity Asserter for Single Sign-On: The Web-only applications implementation handles nearly all SSO use cases. See the appropriate topic for your environment:

  —OAM 11g: Configuring Identity Assertion for SSO with Oracle Access Manager 11g

  —OAM 10g: Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g

• Oracle Web Services Manager-Protected Web Services: Require the AccessGate provided with the Identity Asserter. See the appropriate topic for your environment:

  —OAM 11g: Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g

  —OAM 10g: Configuring Identity Assertion for Oracle Web Services Manager and OAM 10g

• Authenticator: No single sign-on is provided. The Authenticator requests credentials from the user based on the authentication method specified in the application configuration file, web.xml. See the appropriate topic for your environment:

  —OAM 11g: Configuring the Authenticator for Oracle Access Manager 11g

  —OAM 10g: Configuring the Authenticator for Oracle Access Manager 10g

9.2.4.3 Applications Using OAM Security Provider for WebLogic SSPI

The Oracle Access Manager Security Provider for WebLogic SSPI provides authentication, authorization, and single sign-on across J2EE applications that are deployed in the WebLogic platform. The Security Provider for WebLogic SSPI enables WebLogic administrators to use Oracle Access Manager to control user access to business applications.

The Oracle Access Manager Security Provider for WebLogic SSPI provides authentication to Oracle WebLogic Portal resources and supports single sign-on between Oracle Access Manager and Oracle WebLogic Portal Web applications. Apart from this, the Security Provider for WebLogic SSPI also offers user and group management functions.

The Oracle Access Manager Authentication Provider is more easily installed and configured than the Security Provider for WebLogic SSPI. The Authentication Provider offers authentication and single sign-on (SSO) services, and also works with all platforms supported by Oracle WebLogic Server.

If your application has been using the Oracle Access Manager Security Provider for WebLogic SSPI for only authentication and SSO, the deployment is a good candidate for the latest Authentication Provider. However, if your application relies on features other than those offered by the latest Oracle Access Manager Authentication Provider, you can continue to use the Oracle Access Manager 10g Security Provider for WebLogic SSPI.

9.3.4.1 About WebGate Provisioning Methods for Oracle Access Manager 11g

Table 9-2 outlines the methods and tools you can use to provision WebGates for use with OAM 11g. The remote registration tool enables you to specify a small amount or all WebGate parameters using templates.

During remote registration, you must provide the details discussed in Table 9-3.

9.3.4.2 Provisioning a WebGate with Oracle Access Manager 11g

Provisioning a WebGate or AccessGate involves the same steps. You can provision a new instance for use with the Authentication Provider or you can refer to an existing registration when configuring the provider.

In this example, an OAM 10g WebGate is provisioned using the OAMRequest_short.xml template. The registered agent is named my-wl-agent1, protecting /.../*, and declaring a public resource, /public/index.html. Your values will be different.

To provision a WebGate with OAM 11g

1. Acquire the Tool: On the computer to host the WebGate, acquire the remote registration tool and set up the script for your environment. For example:

   1. Locate RREG.tar.gz file in the following path:

      WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz 
      

   2. Untar RREG.tar.gz file to any suitable location. For example: rreg/bin/oamreg.

   3. In the oamreg script, set the following environment variables based on your situation (client side or server side) and information in Table 6–7 in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager:

      
      OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
      JDK_HOME = Java_location_on_the_computer
      

2. Create the registration request:

   1. Locate the *Request_short.xml file and copy it to a new location and name. For example:

      WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
      

      Copy: OAMRequest_short.xml (or OAM 11gRequest.xml)

      To: my-wl-agent1.xml

   2. Edit my-wl-agent1.xml to include details for your environment, and set automatic policy creation to false. For example:

      <OAMRegRequest>
          <serverAddress>http://sample.us.oracle.com:7001</serverAddress>
          <hostIdentifier>my-wl</hostIdentifier>
          <agentName>my-wl-agent1</agentName>
          <primaryCookieDomain>.us.example.com</primaryCookieDomain>
          <autoCreatePolicy>false</autoCreatePolicy>
          <logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
      </OAMRegRequest>
      

      See Also:

      "Creating the Registration Request"in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager

3. Provision the agent. For example:

   1. Locate the remote registration script.

      
      Linux: rreg/bin/oamreg.sh
      Ensure the script has executable permission: chmod +x oamreg.sh
      

      Windows: rreg\bin\oamreg.bat

   2. From the directory containing the script, execute the script using inband mode. For example:

      $ ./bin/oamreg.sh inband input/my-wl-agent1.xml

      Welcome to OAM Remote Registration Tool!
      Parameters passed to the registration tool are:
      Mode: inband
      Filename: ...
      

   3. When prompted, enter the following information using values for your environment:

      Enter your agent username: userame
         Username:  userame
      Enter agent password: ********
      Do you want to enter a Webgate password?(y/n)
          n
      iv.Do you want to import an URIs file?(y/n)
          n
      

   4. Review the final message to confirm that this was a successful registration:

      Inband registration process completed successfully! Output artifacts are 
      created in the output folder"
      

4. Confirm in the Console: Log in to the OAM Administration Console and review the new registration:

   1. From the OAM 11g Console System Configuration tab, navigation pane, expand the Agents nodes to locate the agent you just provisioned:

      
      Agents
      OAM Agents
      10g Agents
      

   2. Double-click the agent's name to display the registration page and review the details, which you will use later. For example:

      Agent Name—During WebGate installation, enter this as the WebGate ID. If you deploy the custom 10g AccessGate, enter this as the AccessGate Name when configuring the OAM Authentication Provider in the WebLogic Administration Console.

      Access Client Password—During WebGate installation, enter this as the WebGate password. If no password was entered, you can leave the field blank.

      Access Server Host Name—Enter the DNS host name for the primary OAM 11g Server with which this WebGate is registered.

   3. OAM Proxy Port—From the OAM Administration Console, System Configuration tab, navigation pane, double click Server Instances and locate the port on which the OAM Proxy is running.

5. Ignore the Obaccessclient.xml file, which is created during provisioning, for now.

6. Proceed as needed for your environment:

   • Agent is Installed: Go to the appropriate topic for your implementation:

     • Configuring Identity Assertion for SSO with Oracle Access Manager 11g

     • Configuring the Authenticator for Oracle Access Manager 11g

     • Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g

     • Configuring Centralized Log Out for Oracle Access Manager 11g

   • Agent is Not Installed:

     11g WebGate: See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

     10g WebGate: See Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

9.3.5.1 Establishing Trust with Oracle WebLogic Server

The following topics explain the tasks you must perform to set up the application for single sign-on with the Oracle Access Manager Identity Asserter:

• Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On

• Confirming mod_weblogic for Oracle Access Manager Identity Asserter

• Establishing Trust between Oracle WebLogic Server and Other Entities

targetAddress localAddress localPort action protocols

9.3.5.2 Configuring Providers in the WebLogic Domain

The information here applies equally to OAM 11g and OAM 10g. This topic is divided as follows:

• About Oracle WebLogic Server Authentication and Identity Assertion Providers

• About the Oracle WebLogic Scripting Tool (WLST)

• Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO

• Setting Up Providers for Oracle Access Manager 11g Identity Assertion

domain_home/config/fmwconfig/jps-config.xml 

$JDEV_HOME/oracle_common/common/bin/

$Middleware_home/oracle_common/wlst

addOAMSSOProvider(loginuri, logouturi, autologinuri)

9.3.5.3 Reviewing the Login Page for the Oracle Access Manager Identity Asserter

As mentioned earlier, a login form shipped with 10g WebGate is used only with OAM 10g Access Server. For OAM 11g, neither the 10g WebGate nor 11g WebGate provide a login page.

Proceed as Follows

1. Configuring Centralized Log Out for Oracle Access Manager 11g

2. Testing Oracle Access Manager Identity Assertion for Single Sign-on

9.3.5.4 Testing Oracle Access Manager Identity Assertion for Single Sign-on

The following procedure describes how to test your Oracle Access Manager Identity Assertion setup.

Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

To validate Oracle Access Manager Identity Assertion for Single Sign-on

1. Enter the URL to access the protected resource in your environment. For example:

   http://ohs_server:port/<protected url>
   

2. Provide appropriate credentials when the login form appears.

   • Successful: The implementation works.

   • Not Successful: See "Troubleshooting Tips for OAM Provider Deployments".

9.3.6.1 Configuring Providers for the Authenticator in a WebLogic Domain

This topic includes a procedure that you can use to add and configure the appropriate Authentication providers in a WebLogic domain.

The Oracle Access Manager Authenticator must be configured along with the Default Authentication Provider in a WebLogic domain.

• DefaultAuthenticator: SUFFICIENT

• OAM Authenticator: OPTIONAL

The following procedure describes this task using the WebLogic Administration Console. You can also add these using the Oracle WebLogic Scripting Tool (WLST).

To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain

1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

   1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      

   2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      

   3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      

2. Go to the Oracle WebLogic Administration Console.

3. With Oracle Fusion Middleware Application Installed:

   1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war 
      

   2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      

4. Go to the Oracle WebLogic Administration Console.

5. Click Lock & Edit, if desired.

6. OAM Authenticator:

   1. Click Security Realms and select the realm you want to configure.

   2. Select Providers, Authentication, and click New to display the Create a New Authentication Provider page

   3. Enter a name and select a type:

      Name OAMAuthN

      Type: OAMAuthenticator

      OK

   4. Click the name of the Authentication provider you have just created to display the Provider Configuration page.

   5. In the Provider Configuration page, set the required values as follows:

      Access Gate Name: The name of the AccessGate used by the Provider. This must match exactly the name of an OAM Agent registration in the OAM Administration Console.

      Note:

      You can have one or more 10g OAM Agents registered with OAM 11g. Be sure to choose the correct Agent registration name.

      Access Gate Password: The same password, if any, that is as defined for the Agent registration (see the OAM Administration Console).

      Primary Access Server: The host:port of the primary Access Server that is associated with this AccessGate in the OAM Administration Console.

      Advanced Configuration: Following are several advanced configuration values.

      Transport Security: The communication mode between Access Server and AccessGate: open, simple, or cert.

      If transport security is Simple or Cert, include the following parameters and values:

      Trust Store: The absolute path of JKS trust store used for SSL communication between the provider and the OAM Server.

      Key Store: The absolute path of JKS key store used for SSL communication between the provider and the OAM Server.

      Key Store Pass Phrase: The password to access the key store.

      Simple mode pass phrase: The password shared by AccessGate and OAM Server for simple communication modes.

      Secondary OAM Server: The host:port of the secondary OAM Server that is associated with this AccessGate in the OAM Administration Console.

      Maximum OAM Server Connections in Pool: The maximum number of connections that the AccessGate opens to the OAM Server. The default value is 10.

      Note:

      The Maximum OAM Server Connections in Pool (or Minimum OAM Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in the OAM Administration Console.

      Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication provider uses to send authentication requests to the Access Server. The default value is 5.

      See Also:

      "Oracle Access Manager Authentication Provider Parameter List" for descriptions and values of the common and provider-specific parameters

   6. Ensure that the parameter Control Flag is set to OPTIONAL initially.

      Note:

      Do not set the parameter Control Flag to REQUIRED until you have verified that the Authentication Provided is operational and configured correctly.

7. In the Change Center, click Activate Changes.

8. DefaultAuthenticator: Under the Providers tab, select DefaultAuthenticator, which changes its control flag to SUFFICIENT.

9. Reorder: Under the Providers tab, reorder the providers so that DefaultAuthenticator is first (OAMAuthenticator follows DefaultAuthenticator).

   Note:

   If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.

10. Oracle Access Manager Authenticator REQUIRED or the Only Authenticator: Perform the following steps to set user rights for booting Oracle WebLogic Server.

    1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).

       Note:

       To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.

    2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

    3. From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.

    4. Select View Conditions for the Admin Role.

    5. Add the group and click Save.

11. Reboot the WebLogic Server.

12. Once the server has started, reset the Authentication Provider parameter Control Flag to the appropriate value (REQUIRED, OPTIONAL, or SUFFICIENT).

    Note:

    The recommended value is REQUIRED. To prevent a known issue, see "JAAS Control Flag".

13. Proceed with "Configuring the Application Authentication Method for the Authenticator".

9.3.6.2 Configuring the Application Authentication Method for the Authenticator

This topic describes how to create the application authentication method for Oracle Access Manager Authenticator.

When you use the Oracle Access Manager Authenticator, all web.xml files in the application EAR file must specify BASIC in the element auth-method for the appropriate realm.

The auth-method can use BASIC or FORM values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).

To configure the application authentication method for the Authenticator

1. Locate the web.xml file in the application EAR file:

   WEB-INF/web.xml 
   

2. Locate the auth-method in login-config and enter BASIC. For example:

   <security-constraint>
   <web-resource-collection>
   <web-resource-name>protected</web-resource-name>
   <url-pattern>/servlet</url-pattern>
   </web-resource-collection>
   <auth-constraint>
   <role-name>auth-users</role-name>
   </auth-constraint>
   </security-constraint>
   <login-config>
   <auth-method>BASIC</auth-method>
   </login-config>
   <security-role>
   <description>Authenticated Users</description>
   <role-name>auth-users</role-name>
   </security-role>
   

3. Save the file.

4. Redeploy and restart the application.

5. Repeat for each web.xml file in the application EAR file.

6. Proceed with "Mapping the Authenticated User to a Group in LDAP".

9.3.6.3 Mapping the Authenticated User to a Group in LDAP

This topic describes how to map the authenticated user to a group in LDAP. To do this, you must edit the weblogic.xml file. For example, you might need to map your role-name auth-users to a group named managers in LDAP.

To map the authenticated user to a group in LDAP for the Oracle Access Manager Authenticator

1. Go to the application's weblogic.xml file.

2. Add the following information for your environment anywhere in the file:

   <weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
   http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" 
   xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
   <security-role-assignment>
   <principal-name>managers</principal-name>
   <role-name>auth-users</role-name>
   </security-role-assignment>
   </weblogic-web-app>
   

3. Save the file.

4. Restart the WebLogic Server.

5. Configure centralized logout as described in "Configuring Centralized Log Out for Oracle Access Manager 11g" and then return here to perform "Testing the Oracle Access Manager Authenticator Implementation".

9.3.6.4 Testing the Oracle Access Manager Authenticator Implementation

After performing all tasks to implement the Authenticator, you can test it by attempting to log in to the application using valid credentials. If the configuration is incorrect, a valid user is denied access.

The following procedure describes how to test your Authenticator setup. Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

To validate the Oracle Access Manager Authenticator implementation

1. Enter the URL to access the protected resource in your environment. For example:

   http://yourdomain.com:port
   

2. Provide appropriate credentials when the login form appears.

   • Successful: The implementation works.

   • Not Successful: See "Troubleshooting Tips for OAM Provider Deployments".

9.3.7.1 Configuring Oracle Web Services Manager Policies for Web Services

This section provides an overview of configuring Oracle Web Services Manager policies to protect Web services.

To use the Identity Asserter with Oracle Web Services Manager, you must set up a Web service with the oracle/wss_oam_token_service_policy and a corresponding client with the oracle/wss_oam_token_client_policy in Oracle Web Services Manager.

About oracle/wss_oam_token_service_policy

This Oracle Web Services Manager policy contains the policy assertion oracle/wss_oam_token_service_template. This template uses the credentials in the WS-Security header's binary security token to authenticate users against the Oracle Access Manager identity store.

The Oracle Access Manager Identity Asserter uses the ObSSOCookie token to assert the identity of users who try to access a Web service protected by the oracle/wss_oam_token_service_policy policy. A Web service that is protected by this policy must be presented with an ObSSOCookie token in a SOAP header. That is, the Web service consumes the ObSSOCookie token; it is not involved in how the token is generated. Specifically, the WebLogic Server security service detects the token type and invokes the Oracle Access Manager Identity Asserter. The Oracle Access Manager Identity Asserter then validates the ObSSOCookie token against the Oracle Access Manager Access Server and obtains the username. The username is populated as the principal in the authenticated subject.

The Web service client, for example the Web application, must obtain the ObSSOCookie token to send it to the Web service. This is typically done using an AccessGate. AccessGate challenges the Web service client user for credentials (depending on the authentication scheme configured in Oracle Access Manager) and authenticates the user. The WebGate sends the ObSSOCookie to the user's browser upon successful authentication

The Web service client then sends the ObSSOCookie token in the SOAP request to the Web service.

About oracle/wss_oam_token_client_policy

This Oracle Web Services Manager policy contains the following policy assertion: oracle/wss_oam_token_client_template. This template inserts Oracle Access Manager credentials into the WS-Security header as part of the binary security token.

oracle/wss_oam_token_client_policy is the analogous client policy to the oracle/wss_oam_token_service_policy service endpoint policy. This policy can be enforced on any SOAP-based endpoint.

The following task overview outlines the procedures you must perform.

Task overview: Setting policies in Oracle Web Services Manager

1. Using Oracle Web Services Manager, set up a Web service with the oracle/wss_oam_token_service_policy policy.

2. Using Oracle Web Services Manager, set up a corresponding client for the Web service with the oracle/wss_oam_token_client_policy policy.

3. Configuring Providers in a WebLogic Domain for Oracle Web Services Manager.

9.3.7.2 Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several Authentication providers must be configured and ordered in a WebLogic domain:

• OAM Identity Asserter: REQUIRED

• OID Authenticator: SUFFICIENT

• DefaultAuthenticator: SUFFICIENT

This procedure is nearly identical to the one for the Oracle Access Manager Identity Asserter with OAM 11g. The difference in this case is that Oracle Web Services Manager requires the custom 10g AccessGate and additional provider-specific values:

• Primary Access Server: Specify the host and part. For example: mnop:8888

• Access Gate Name: The name of the AccessGate registration protecting the application. For example: AG1

• Access Gate Password: The AccessGate password as specified in the OAM Administration Console.

You can add these using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

To set up providers in a WebLogic domain

1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

   1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      

   2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      

   3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      

2. Log in to the Oracle WebLogic Administration Console.

3. OAM Identity Asserter: Perform the following steps to add this provider:

   1. Click Security Realms, Default Realm Name, and click Providers.

   2. Click Authentication, click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

   3. In the Authentication Providers table, click the newly added authenticator.

   4. On the Common tab, set the Control Flag to REQUIRED, and click Save.

   5. Click the Common tab, specify ObSSOCookie as the chosen Action type for the 10g custom AccessGate, and click Save.

   6. Click the Provider Specific tab and configure these parameters:

      Primary Access Server: Specify the host and part. For example: abcd:7777

      Access Gate Name: The name of the OAM Agent registration protecting the application. For example: AG1

      Access Gate Password: The AccessGate password, if any, that was specified in during provisioning.

      Save.

4. OID Authenticator: Perform the following steps to add this provider.

   1. Click Security Realms, Default Realm Name, and click Providers

   2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click OK.

   3. In the Authentication Providers table, click the newly added authenticator.

   4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

   5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)

      Note:

      Do not set the All Groups filter as the default works fine as is.

      Click Save.

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

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

   2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

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

   4. Click Save.

6. Reorder Providers:

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

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

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

   4. 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 "Configuring Centralized Log Out for Oracle Access Manager 11g", and then return here to perform "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 the Authentication Provider with Oracle Access Manager 11g".

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

9.3.8.1 Logout for 11g WebGate and OAM 11g

Several elements in the OAM 11g Agent registration page enable centralized logout for OAM 11g WebGates. After agent registration, the ObAccessClient.xml file is populated with the information.

11g WebGate logout options that you must have in the agent registration include the following:

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

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

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

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

For more information, see "Configuring Centralized Logout for 11g WebGate with OAM 11g Server" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

9.3.8.2 Logout for 10g WebGate with Oracle Access Manager 11g

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

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: For example, WebGate_install_dir/oamsso/logout.html.

2. In your logout.html, confirm that the logOutUrls parameter is configured for each resource WebGate and that <callBackUri> is the second value as part of 'logOutUrls'.

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.

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

For more information, see "Configuring Centralized Logout for 10g WebGate with OAM 11g Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

9.4.1.1 About Oracle Access Manager 10g Installation and Setup

This topic provides a brief installation and setup overview if you are new to Oracle Access Manager.

Access Servers: For the Oracle Access Manager Authentication Provider, you need two Access Servers for WebGates or AccessGates: one primary server and one secondary server. Currently, only one secondary Access Server is supported. Installing Access Servers includes:

• Adding an Access Server configuration profile in the Access System Console for the primary server. Ensure that the Access Management Service is On (also known as Policy Manager API Support Mode).

• Adding a secondary Access Server configuration profile with the Access Management Service On.

• Installing the primary Access Server instance.

• Installing the secondary Access Server instance.

WebGate/AccessGate: Whether you need a WebGate or an AccessGate depends on your use of the Oracle Access Manager Authentication Provider. For instance, the:

• Identity Asserter for Single Sign-On: Requires a separate WebGate and configuration profile for each application to define perimeter authentication. Ensure that the Access Management Service is On.

• Authenticator or Oracle Web Services Manager: Requires a separate AccessGate and configuration profile for each application. Ensure that the Access Management Service is On.

About OAM 10g WebGate/AccessGate Profiles and Policy Domains

This topic introduces the WebGate/AccessGate profiles, policy domains, and the methods you can use the create these.

While there are subtle differences between WebGates and AccessGates, these terms are often used interchangeably. In the Access System Console, the configuration profile for WebGates or AccessGates is known as an AccessGate profile. The Policy Manager is where an Oracle Access Manager policy domain is created.

Access System Console Method: Enables users with specific Oracle Access Manager administration rights to enter information and set parameters directly in Oracle Access Manager. This method is required if you are using the Authenticator, or if you have Oracle Web Services Manager policies protecting Web services.

OAMCfgTool Method: Application administrators who are implementing the Identity Asserter for single sign-on, can use OAMCfgTool to create a new WebGate profile for a fresh Web Tier. Required parameters are provisioned using values for your environment specified on the command line. Default values are accepted for non-required parameters; the Access Management Service is set to On. After creating a profile, values can be modified in the Access System Console.

Each AccessGate profile must include the following parameters; those marked with an asterisk, *, are provisioned with OAMCfgTool:

• *AccessGate Name—A unique name without spaces. With OAMCfgTool the name is derived from the app_domain value, appended with _AG.

• *Hostname—The name of the computer where the WebGate/AccessGate is or will be installed. With OAMCfgTool the app_domain value is used as the host name.

• *AccessGate Password—A unique password to verify and identify the component. This prevents unauthorized AccessGates from connecting to Access Servers and obtaining policy information. With OAMCfgTool, this is specified with the app_agent_password parameter. This should differ for each WebGate/AccessGate instance.

• Transport Security—The level of transport security between the Access Server and associated WebGates (these must match). The default value is Open. You can specify a different value with OAMCfgTool oam_aaa_mode value.

• *Preferred HTTP Host—The host name as it appears in all HTTP requests as users attempt to access the protected Web server. The host name in the HTTP request is translated into the value entered into this field, regardless of the way it was defined in a user's HTTP request. With OAMCfgTool the Preferred HTTP Host is the app_domain value.

  The Preferred Host function prevents security holes that can be inadvertently created if a host's identifier is not included in the Host Identifiers list. However, it cannot be used with virtual Web hosting. For virtual hosting, you must use the Host Identifiers feature.

• *Primary HTTP Cookie Domain: The Web server domain on which the WebGate is deployed. The cookie domain is required to enable single sign-on among Web servers; each must have the same Primary HTTP Cookie Domain value. Use the cookie_domain parameter with the OAMCfgTool to set this value.

About Administrative Requirements for AccessGate Profiles and Policy Domains

This topic introduces the administrative rights needed for the methods you can use when creating new WebGate and AccessGate profiles and policy domains for Oracle Access Manager.

An Oracle Access Manager Master Access Administrator must create the first policy domain after the policy domain root is defined. He or she can then create policy domains for URLs beneath the first one and delegate administration of those policy domains to other administrators.

Access System Console Method: You must be a Master or Delegated Access Administrator can use the Access System Console to create a new AccessGate profile, associate it with an Access Server, and create an authentication scheme. Master or Delegated Access Administrators can also use the Policy Manager to create a policy domain. The following deployments require this method:

• Authenticator

• Identity Asserter when Oracle Web Services Manager is protecting Web services

OAMCfgTool Method: You do not need specific Oracle Access Manager administration rights for OAMCfgTool, which automates creating and associating a WebGate profile and creating a new policy domain. However, this method can be used for only Identity Assertion. In a:

• Fresh Web Tier: Use OAMCfgTool to streamline creating a new WebGate profile and policy domain for Identity Asserter only.

  After creating the profile and policy domain with OAMCfgTool, these can be modified in the Access System Console.

  See Also:

  "About Using OAMCfgTool"

• Existing Web Tier: When one or more WebGates exist in the Web Tier, no new WebGate is needed. However, you can specify an existing host identifier to make newly established policies enforceable by an existing WebGate.

9.4.1.2 Installing Components and Files for Authentication Providers and OAM 10g

The following task overview outlines the components and files that must be installed and where to locate more information.

Unless specifically stated, all details apply whether you intend to deploy the Identity Asserter for single sign-on, or the Authenticator, or if Oracle Web Services Manager policies are protecting Web services.

Task overview: Installing required components and files for Oracle Access Manager 10g Authentication Provider

1. An Oracle Internet Directory or Oracle Sun One LDAP directory server configured to be used by the Oracle Access Manager Access Server. Ensure that the directory server is tuned for your deployment.

   See Also:

   The following Release 11g (11.1.1.1.0) manuals

   • Oracle Fusion Middleware Installation Guide for Oracle Identity Management

   • Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

2. Install and set up Oracle WebLogic Server 10.3.1+.

   See Also:

   Item 3 in this list, and the Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server

3. Optional: Install a Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example):

   Note:

   Without a Fusion Middleware application, you must acquire the required JAR and WAR files as described in later procedures.

   1. Confirm the location of required JAR files in the following Fusion Middleware path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
      

   2. Locate the console-extension WAR file in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov 
      ider.war
      

   3. Copy the WAR file to the following path in the WebLogic Server home:

      WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
      

4. Install OHS 11g for the Oracle Access Manager 10g (10.1.4.3) WebGate, if needed:

   • Authenticator or Oracle Web Services Manager: No Web server is required for the custom AccessGate. The protected resource is accessed using its URL on the Oracle WebLogic Server.

   • Oracle Access Manager Identity Asserter: Requires Oracle HTTP Server 11g Web server configured as a reverse proxy in front of Oracle WebLogic Server.

5. Install Oracle Access Manager 10g (10.1.4.3) components and perform initial setup as follows:

   See Also:

   "About Oracle Access Manager 10g Installation and Setup"

   1. Install an Identity Server; install a WebPass; set up the Identity System.

   2. Install and set up Policy Manager. Ensure that the policy protecting the Policy Manager, /access, is created and enabled, as well as the default authentication schemes.

   3. Install Access Servers (one as a primary server and one as a secondary server for WebGate).

      • Add an Access Server configuration profile in the Access System Console for the primary server for WebGate. Ensure that the Access Management Service is On (also known as Policy Manager API Support Mode).

      • Add a secondary Access Server configuration profile with the Access Management Service On.

      • Install the primary Access Server instance and then install the secondary Access Server instance.

        Note:

        Only one secondary Access Server is supported

   4. WebGate for Identity Asserter for Single Sign-On: In an existing Web Tier with one or more WebGates, no new WebGates or profiles are needed.

      See Also:

      "About Using OAMCfgTool"

      In a fresh Web Tier, you must create a profile to define the WebGate for perimeter authentication, as follows:

      • Create an AccessGate configuration profile to define the WebGate for perimeter authentication. Ensure that the Access Management Service is On. You can use the OAMCfgTool or Access System Console.

      • Associate the WebGate profile with a primary and a secondary Access Server.

      • Install a WebGate for Oracle HTTP Server 11g configured as a reverse proxy for every application.

      • Repeat until you have a profile and a WebGate protecting each application.

   5. AccessGate: For the Authenticator, or when you have Oracle Web Services, Manager you must add a new profile for custom AccessGates in the Access System Console

      See Also:

      "About OAM 10g WebGate/AccessGate Profiles and Policy Domains"

      • Add an AccessGate configuration profile in the Access System Console and ensure that the Access Management Service is On.

      • Associate the AccessGate profile with a primary and a secondary Access Server.

      • Deploy the custom AccessGate in oamAuthnProvider.jar.

      • Repeat until you have a profile and a AccessGate protecting each application.

6. Proceed as follows:

   • Create Resource Types: "Creating Resource Types in Oracle Access Manager 10g" must be performed if you use the Oracle Access Manager Authenticator or if you have Oracle Web Services Manager policies protecting Web services.

   • Identity Asserter for Single Sign-On: Perform tasks in "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g".

   • Authenticator: Perform tasks in "Configuring the Authenticator for Oracle Access Manager 10g".

   • Oracle Web Services Manager: Perform tasks in "Configuring Identity Assertion for Oracle Web Services Manager and OAM 10g".

   • "Troubleshooting Tips for OAM Provider Deployments".

9.4.1.3 Creating Resource Types in Oracle Access Manager 10g

This section describes how to create resource types in Oracle Access Manager to identify the types of resources that you want the policy domain to protect. You use the Oracle Access Manager Access System Console to define resource types as described here.

Defining the wl_authen resource type in Oracle Access Manager is required only when you are using:

• Oracle Access Manager Authenticator

• Identity Asserter with Oracle Web Services Manager

To define resource types in Oracle Access Manager 10g

1. Go to the Access System Console and log in.

2. Select the Access System Configuration tab, and then click Common Information Configuration, Resource Type Definitions, to display the List All Resource Types page.

3. On the List All Resource Types page, click Add, to display the Define a new Resource Type page.

4. Define the resource type with the following details:

   • Name: wl_authen

   • Display name: wl_authen

   • Resource matching: Case insensitive

   • Resource operation: LOGIN

5. Save the resource type you just defined.

6. Proceed as follows:

   • Authenticator: "Configuring the Authenticator for Oracle Access Manager 10g"

   • Oracle Web Services Manager: "Configuring Identity Assertion for Oracle Web Services Manager and OAM 10g"

9.4.2.1 Establishing Trust with Oracle WebLogic Server

The following topics explain the tasks you must perform to set up the application for single sign-on with the Oracle Access Manager Identity Asserter:

• Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On

• Confirming mod_weblogic for Oracle Access Manager Identity Asserter

• Establishing Trust between Oracle WebLogic Server and Other Entities

targetAddress localAddress localPort action protocols

9.4.2.2 Configuring the Authentication Scheme for the Identity Asserter

This topic focuses on using OAMCfgTool for OAM 10g. If you are using OAM 11g, skip this topic and instead perform tasks in "Provisioning an OAM Agent with Oracle Access Manager 11g".

After setting up your application, you must protect it with Oracle Access Manager. To help automate this task, Oracle provides the command-line tool: OAMCfgTool in the Fusion Middleware application-provided oamcfgtool.jar file for OAM 10g.

While you can perform steps manually in the Access System Console and Policy Manager, you can optionally use OAMCfgTool to setup and validate a form-based authentication scheme, a policy domain for the application, and Oracle Access Manager access policies required for Identity Assertion for single sign-on. Additionally, you can create a new WebGate profile in a fresh Web Tier or modify a WebGate profile in an existing Web Tier.

For more information, see:

• About Using OAMCfgTool

• OAMCfgTool Process Overview

• Using OAMCfgTool to Create an Authentication Scheme, Policy Domain, and a WebGate Profile for Identity Assertion

9.4.2.2.3 Sample Policy Domain and AccessGate Profile Created with OAMCfgTool

This topic describes and illustrates the results of running OAMCfgTool when viewed in Oracle Access Manager:

• My Policy Domains

• Policy Domain, General Tab

• Policy Domain, Resources Tab

• Policy Domain, Authorization Rules Tab

• Policy Domain, Default Rules Tab

• Policy Domain, Policies Tab

• Policy Domain, Delegated Access Admins Tab

• Host Identifiers

• AccessGate Profile

Note:

This topic focuses on using OAMCfgTool for OAM 10g. If you are using OAM 11g, see the chapter on remote registration in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

My Policy Domains

Name: app_domain value specified with OAMCfgTool

Policy Domain, General Tab

Figure 9-9 illustrates the General tab in a sample policy domain created with OAMCfgTool. The Description is provided automatically.

Name: app_domain value specified with OAMCfgTool
Description: includes the app_domain value created by user@hostname ...

Note:

For descriptions only, the Java API retrieves the current user from the operative platform and the name of the computer host: user@hostname.

Figure 9-9 Sample OAMCfgTool Policy Domain General Tab

Description of "Figure 9-9 Sample OAMCfgTool Policy Domain General Tab"

Policy Domain, Resources Tab

Figure 9-10 illustrates the Resources tab in a sample policy domain created with OAMCfgTool. The http resource type is the default. The host identifier and URL prefixes are derived from OAMCfgTool parameters and the values you enter. The Description is provided automatically.

Host Identifier: app_domain value
URL Prefix: protected_uris values

Figure 9-10 Sample OAMCfgTool Policy Domain Resources Tab

Description of "Figure 9-10 Sample OAMCfgTool Policy Domain Resources Tab"

Policy Domain, Authorization Rules Tab

Figure 9-11 illustrates the Authorization Rules tab in a sample policy domain created with OAMCfgTool. Details found on sub tabs follow the figure. Authorization rules are automatically configured for the policy domain when you use OAMCfgTool.

Figure 9-11 Sample OAMCfgTool Policy Domain Authorization Rules Tab

Description of "Figure 9-11 Sample OAMCfgTool Policy Domain Authorization Rules Tab"

Timing Conditions: There are no timing conditions defined. This rule is always valid.
Actions: There are no actions defined.
Allow Access: Role: Anyone
Deny Access: No one is denied access.

Policy Domain, Default Rules Tab

Figure 9-12 illustrates the Default Rules tab in a sample policy domain created with OAMCfgTool. All values are configured automatically for the policy domain; details on sub tabs follow the figure.

Authentication Rule
General, see Figure 9-12.
Actions: There are no actions defined.

Figure 9-12 Sample OAMCfgTool Policy Domain Default Rules Tab

Description of "Figure 9-12 Sample OAMCfgTool Policy Domain Default Rules Tab"

Authorization Expression
Authorization Expression: Default_Authorization
Duplicate Actions: No policy defined for this Authorization Expression. The
Access System level default policy for dealing with duplicate
action headers are employed.
Actions
Authorization Success
Return Type Name Attribute
HeaderVar REMOTE_USER uid
HeaderVar OAM_REMOTE_USER uid

Policy Domain, Policies Tab

Figure 9-13 illustrates the Policies tab, General sub tab, in a sample policy domain created using parameters and values that you specify with OAMCfgTool. The host identifiers are based on your app_domain value. Details on other sub tabs follow the figure.

Figure 9-13 Sample OAMCfgTool Policy Domain Policies Tab

Description of "Figure 9-13 Sample OAMCfgTool Policy Domain Policies Tab"

Authentication Rule
General
Name: Anonymous
Description: Authentication scheme allows un-authenticated access to some
URIs
Authentication Scheme: Anonymous Authentication (Default)
Actions: There are no actions defined.

Authorization Expression
There is no Authorization Expression defined.

Audit Rule
There is no Master Audit Rule defined.
If you would like to add an auditing rule to this Policy, please contact your
Access System Administrator.

Policy Domain, Delegated Access Admins Tab

Figure 9-14 illustrates the Delegated Access Admins tab in a sample policy domain created using OAMCfgTool. No parameters are specified with the tool to set up delegated rights for Master Web resource Admins.

Figure 9-14 OAMCfgTool Policy Domain Delegated Access Admins Tab

Description of "Figure 9-14 OAMCfgTool Policy Domain Delegated Access Admins Tab"

See Also:

"Protecting Resources with Policy Domains" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

Host Identifiers

You can find the Host Identifiers created with OAMCfgTool in the Access System Console, under the Access System Configuration tab.

Figure 9-15 illustrates a sample host identifiers created using OAMCfgTool. As described here, required parameters are derived from the value entered with OAMCfgTool app_domain parameter. A Description is provided by OAMCfgTool.

Figure 9-15 Sample OAMCfgTool Host Identifiers

Description of "Figure 9-15 Sample OAMCfgTool Host Identifiers"

AccessGate Profile

Figure 9-16 illustrates a sample AccessGate profile created using OAMCfgTool when the web_domain parameter is omitted. The profile is in the Access System Console. As described here, required profile parameters are derived from values entered with OAMCfgTool. Other profile parameters use default values. A Description is provided by OAMCfgTool.

Name: app_domain value _AG
Hostname: app_domain value
Access Gate Password: app_agent_password value
ASDK Client
Access Management Service: On
Web Server Client
Primary HTTP Cookie Domain: cookie_domain value
Preferred HTTP Host: app_domain value

Figure 9-16 Sample OAMCfgTool AccessGate Profile

Description of "Figure 9-16 Sample OAMCfgTool AccessGate Profile"

9.4.2.3 Configuring Providers in the WebLogic Domain

This topic is divided as follows:

• About Oracle WebLogic Server Authentication and Identity Assertion Providers

• About the Oracle WebLogic Scripting Tool (WLST)

• Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO

• Setting Up Providers for Oracle Access Manager Identity Assertion

domain_home/config/fmwconfig/jps-config.xml 

$JDEV_HOME/oracle_common/common/bin/

$Middleware_home/oracle_common/wlst

addOAMSSOProvider(loginuri, logouturi, autologinuri)

9.4.2.4 Setting Up the Login Form for the Identity Asserter and OAM 10g

This topic introduces the login form provided for the Oracle Access Manager Identity Asserter for single sign-on and provides a procedure that you can use to deploy the form.

The form shown in Figure 9-17 is provided with the WebGate installation for Oracle HTTP Server 11g Web server. The form contains two fields (UserID and Password) and a Login button. The variables in this form are required by the Form Login authentication scheme that was generated by the OAMCfgTool and used in the policy domain protecting resources for Identity Assertion.

Figure 9-17 Default Login Form for Single Sign-On with 10g WebGates

Description of "Figure 9-17 Default Login Form for Single Sign-On with 10g WebGates"

The following information is added to the Oracle HTTP Server 11g Web server httpd.conf file during WebGate installation and configuration. It ensures that WebGate for Oracle HTTP Server 11g can find the default login form.

Alias /oamsso "/oam/webgate/access/oamsso"

Delete the following three lines if they exist:

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

The following procedure guides as you set up the login form for your environment.

To set up the login form for Identity Assertion and OAM 10g

1. Verify that the login form is located in the following Oracle HTTP Server11g WebGate path on the computer hosting the application:

   WebGate_install_dir/access/oamsso/login.html

2. From your browser, go to the following URL:

   http://WebGatehost:port/oamsso/login.html

3. Confirm that the /access policy was created and enabled to protect Policy Manager resources to ensure that the login process can redirect authenticated users to the originally requested application URL.

4. Proceed to:

   • Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates

   • Testing Identity Assertion for SSO with OAM 10g

9.4.2.5 Testing Identity Assertion for SSO with OAM 10g

The following procedure describes how to test your Oracle Access Manager Identity Assertion setup.

Alternatively, you can run Access Tester within Oracle Access Manager 10g to test your policy domain, as described in the 10g Oracle Access Manager Access Administration Guide.

To validate Identity Assertion for SSO with OAM 10g

1. Enter the URL to access the protected resource in your environment. For example:

   http://ohs_server:port/<protected url>
   

2. Provide appropriate credentials when the login form appears.

   • Successful: The implementation works.

   • Not Successful: See "Troubleshooting Tips for OAM Provider Deployments".

9.4.3.1 Creating an Authentication Scheme for the Authenticator

This topic describes how to create an authentication scheme for the policy domain you will define for the Authenticator later. The Oracle Access Manager authentication scheme must be available before you create the policy domain.

With the Authenticator, the user is challenged for credentials based on the authentication method that is configured within the application web.xml. However, an Oracle Access Manager authentication scheme is required for the policy domain.

9.4.3.2 Configuring a Policy Domain for the Oracle Access Manager Authenticator

After creating an authentication scheme for the Authenticator, you must create a policy domain in Oracle Access Manager to user the scheme.

A policy domain in Oracle Access Manager includes several types of information. Individual tabs are provided where you can enter specific details, as shown in Figure 9-18.

Figure 9-18 Create Policy Domain Page in the Oracle Access Manager Policy Manager

Description of "Figure 9-18 Create Policy Domain Page in the Oracle Access Manager Policy Manager"

For more information, see the following topics:

• About Creating a Policy Domain

• Creating a Policy Domain and Access Policies for the Authenticator

9.4.3.3 Configuring Providers for the Authenticator in a WebLogic Domain

This topic includes a procedure that you can use to add and configure the appropriate Authentication Providers in a WebLogic domain.

The Oracle Access Manager Authenticator must be configured along with the Default Authentication Provider in a WebLogic domain.

• DefaultAuthenticator: SUFFICIENT

• OAM Authenticator: OPTIONAL

The following procedure describes this task using the WebLogic Administration Console. You can also add these using the Oracle WebLogic Scripting Tool (WLST).

To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain

1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

   1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      

   2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      

   3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      

2. Go to the Oracle WebLogic Administration Console.

3. With Oracle Fusion Middleware Application Installed:

   1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war 
      

   2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      

4. Go to the Oracle WebLogic Administration Console.

5. Click Lock & Edit, if desired.

6. OAM Authenticator:

   1. Click Security Realms and select the realm you want to configure.

   2. Select Providers, Authentication, and click New to display the Create a New Authentication Provider page

   3. Enter a name and select a type:

      Name OAMAuthN

      Type: OAMAuthenticator

      OK

   4. Click the name of the Authentication Provider you have just created to display the Provider Configuration page.

   5. In the Provider Configuration page, set the required values as follows:

      Access Gate Name: The name of the AccessGate profile used by the provider. This must match exactly the name in the AccessGate configuration profile in the Access System Console.

      Note:

      You might have only one AccessGate configuration profile for the Authenticator.

      Access Gate Password: The same password, if any, that is as defined for the AccessGate configuration profile in the Access System Console.

      Primary Access Server: The host:port of the primary Access Server that is associated with this AccessGate in the Access System Console.

      Advanced Configuration: Following are several advanced configuration values.

      Transport Security: The communication mode between Access Server and AccessGate: open, simple, or cert.

      If transport security is Simple or Cert, include the following parameters and values:

      Trust Store: The absolute path of JKS trust store used for SSL communication between the provider and the Oracle Access Server.

      Key Store: The absolute path of JKS key store used for SSL communication between the provider and the Oracle Access Server.

      Key Store Pass Phrase: The password to access the key store.

      Simple mode pass phrase: The password shared by AccessGate and Access Server for simple communication modes.

      Secondary Access Server: The host:port of the secondary Access Server that is associated with this AccessGate in the Access System Console.

      Maximum Access Server Connections in Pool: The maximum number of connections that the AccessGate opens to the Access Server. The default value is 10.

      Note:

      The Maximum Access Server Connections in Pool (or Minimum Access Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in profiles within the Access System Console.

      Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication Provider uses to send authentication requests to the Access Server. The default value is 5.

      See Also:

      "Oracle Access Manager Authentication Provider Parameter List" for descriptions and values of the common and provider-specific parameters

   6. Ensure that the parameter Control Flag is set to OPTIONAL initially.

      Note:

      Do not set the parameter Control Flag to REQUIRED until you have verified that the Authentication Provided is operational and configured correctly.

7. In the Change Center, click Activate Changes.

8. DefaultAuthenticator: Under the Providers tab, select DefaultAuthenticator, which changes its control flag to SUFFICIENT.

9. Reorder: Under the Providers tab, reorder the providers so that DefaultAuthenticator is first (OAMAuthenticator follows DefaultAuthenticator).

   Note:

   If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication Provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.

10. Oracle Access Manager Authenticator REQUIRED or the Only Authenticator: Perform the following steps to set user rights for booting Oracle WebLogic Server.

    1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).

       Note:

       To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.

    2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

    3. From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.

    4. Select View Conditions for the Admin Role.

    5. Add the group and click Save.

11. Reboot the WebLogic Server.

12. Once the server has started, reset the Authentication Provider parameter Control Flag to the appropriate value (REQUIRED, OPTIONAL, or SUFFICIENT).

    Note:

    The recommended value is REQUIRED. To prevent a known issue, see "JAAS Control Flag".

13. Proceed with "Configuring the Application Authentication Method for the Authenticator".

9.4.3.4 Configuring the Application Authentication Method for the Authenticator

This topic describes how to create the application authentication method for Oracle Access Manager Authenticator.

When you use the Oracle Access Manager Authenticator, all web.xml files in the application EAR file must specify BASIC in the element auth-method for the appropriate realm.

The auth-method can use BASIC or FORM values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).

To configure the application authentication method for the Authenticator

1. Locate the web.xml file in the application EAR file:

   WEB-INF/web.xml 
   

2. Locate the auth-method in login-config and enter BASIC. For example:

   <security-constraint>
   <web-resource-collection>
   <web-resource-name>protected</web-resource-name>
   <url-pattern>/servlet</url-pattern>
   </web-resource-collection>
   <auth-constraint>
   <role-name>auth-users</role-name>
   </auth-constraint>
   </security-constraint>
   <login-config>
   <auth-method>BASIC</auth-method>
   </login-config>
   <security-role>
   <description>Authenticated Users</description>
   <role-name>auth-users</role-name>
   </security-role>
   

3. Save the file.

4. Redeploy and restart the application.

5. Repeat for each web.xml file in the application EAR file.

6. Proceed with "Mapping the Authenticated User to a Group in LDAP".

9.4.3.5 Mapping the Authenticated User to a Group in LDAP

This topic describes how to map the authenticated user to a group in LDAP. To do this, you must edit the weblogic.xml file. For example, you might need to map your role-name auth-users to a group named managers in LDAP.

To map the authenticated user to a group in LDAP for the Oracle Access Manager Authenticator

1. Go to the application's weblogic.xml file.

2. Add the following information for your environment anywhere in the file:

   <weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
   http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" 
   xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
   <security-role-assignment>
   <principal-name>managers</principal-name>
   <role-name>auth-users</role-name>
   </security-role-assignment>
   </weblogic-web-app>
   

3. Save the file.

4. Restart the WebLogic Server.

5. Proceed to:

   • Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates

   • Testing the Oracle Access Manager Authenticator Implementation

9.4.3.6 Testing the Oracle Access Manager Authenticator Implementation

After performing all tasks to implement the Authenticator, you can test it by attempting to log in to the application using valid credentials. If the configuration is incorrect, a valid user is denied access.

The following procedure describes how to test your Authenticator setup. Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

To validate the Oracle Access Manager Authenticator implementation

1. Enter the URL to access the protected resource in your environment. For example:

   http://yourdomain.com:port
   

2. Provide appropriate credentials when the login form appears.

   • Successful: The implementation works.

   • Not Successful: See "Troubleshooting Tips for OAM Provider Deployments"

9.4.4.1 Creating an Policy Domain for Use with Oracle Web Services Manager

This topic describes how to set up a policy domain for use by the Oracle Access Manager Identity Asserter when you have Oracle Web Services Manager protecting Web services. You must be a Master or Delegated Access Administrator in Oracle Access Manager to create, view, or modify a policy domain.

The following unique values are required in this policy domain:

• Requires the default Basic over LDAP Authentication scheme (set up with Policy Manager) internally to authenticate users and to protect URL resources prefixed with /Authen/SSOToken.

• Protects resources of type wl_authen, which were defined in "Creating Resource Types in Oracle Access Manager 10g"

• Requires a default authentication rule with no actions, which you set up in the following procedure

• Requires a default authorization rule with actions, which you set up in the following procedure.

The following procedure walks you through creating a policy domain for use with Oracle Web Services Manager and the Oracle Access Manager Identity Asserter.

To create a policy domain for the Identity Asserter with Oracle Web Services Manager

1. Go to the Policy Manager and log in. For example:

   http://Webserver:port/access/oblix
   

   where Webserver refers to computer that hosts the Policy Manager Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System Console.

2. Click Policy Manager.

3. Click Create Policy Domain in the left navigation pane to display the Create Policy Domain page.

4. General Tab: Fill in a name and optional description that appears in pages showing lists of policy domains, and then click Save. For example:

   Name: OAM IA OWSM

   Description: Used by Identity Asserter with Oracle Web Services Manager

   Note:

   Do not enable this policy domain until you finish all details.

5. Resources Tab: Click the Resources tab, click the Add button, select resource types, enter URL prefixes, and save as follows:

   Resource Type: wl_authen

   URL prefix: /Authen/SSOToken

   Description: Used by IA OWS to validate SSO token

   Save.

6. Authorization Rules Tab: Add an authorization rule to use in an Authorization Expression later.

   Click the Authorization Rules tab, then click the Add button

   1. General Tab: For Authorization Rules, enter a rule name and, optionally, a brief description.

      Name: Default_OAM_IA_OWS_AuthZ_Rule

      Description: For use with OWS and Identity Asserter.

      Enabled: Yes

      Allow takes precedence: No

      Update Cache: Yes (updates all Access Server caches immediately)

   2. Timing Conditions: None required for this scenario.

   3. Actions: None required on this tab. Instead, you set these up under the Default Rules tab.

   4. Allow Access: Add details that define to whom the Allow Access part of the rule applies.

      Role: Any one

   5. Deny Access: Not Needed for this scenario.

   6. Return to the General tab for Authorization Rules and enable the rule so that you can add it to an authorization expression later.

      See Also:

      Chapter 6 in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager for details about configuring authorization schemes and rules.

7. Default Rules Tab: From here you can add the authentication rule, authorization expression, and audit rule for this policy domain. These default rules apply to the resources it contains, unless the resource is protected by a specific policy.

   Click Default Rules, and then click Add.

   1. Authentication Rule: A policy domain must have at least one authentication rule, which specifies one authentication scheme and optional authentication actions. Enter a Name, optional description, and choose an Authentication Scheme.

      General tab: Fill in the as follows:

      Name: Default AuthN Rule

      Description: Default Rule for OAM IA OSW

      Authentication Scheme: Basic over LDAP

      Click Save.

      Actions tab: No authentication actions are needed in the default rule for Oracle Web Services Manager.

      Note:

      With Oracle Web Services Manager you need an Authorization rule.

   2. Authorization Expression: The authorization expression in the default rules for a policy domain applies to all resources of the domain unless those resources are protected by a policy containing an expression.

      Click the Authorization Expression tab, and then click Add.

      Expression tab: Select the authorization rule you created in Step 6:

      Select Authorization Rule: Default_OAM_IA_OWS_AuthZ_Rule

      Click Add.

      Click Save.

      Actions tab: In Step 6 you defined to whom the Allow Access part of a rule applies. Here, you specify actions for Authorization success for both rules and expressions.

      Click Actions, click Add, and then create a return action on Authorization Success with the following to specify what actions should be invoked when authorization succeeds.

      Authorization Success: Applies to Allow Access conditions.

      Return Type: WL_REALM

      Return Name: uid

      Return Attribute: uid

      Click Save.

      Note:

      Return Attribute uid should match the value of the login parameter for the user name to help identify the user uniquely in the Oracle Access Manager LDAP repository. Here, uid is the canonical name of the login attribute. If your LDAP directory uses a different attribute as the login attribute, the Name should still be "uid". However, the Return Attribute would be whatever your login attribute is configured as (mail, for example). Be careful to put these values under Return Attribute (not Return Value).

8. Policies Tab: No policies are needed. Default Rules apply.

9. Delegated Access Admins: When adding URL prefixes to a policy domain, the Delegated Access Administrator must specify a server hosting the URL prefix.

   See Also:

   Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager, "Delegating Policy Domain Administration"

10. Validate Policy Domain: Click My Policy Domains, click the new policy domain you created, then click View As a Page to see all specifications at once.

11. Proceed with "Configuring Oracle Web Services Manager Policies for Web Services".

9.4.4.2 Configuring Oracle Web Services Manager Policies for Web Services

This section provides an overview of configuring Oracle Web Services Manager policies to protect Web services.

To use the Identity Asserter with Oracle Web Services Manager, you must set up a Web service with the oracle/wss_oam_token_service_policy and a corresponding client with the oracle/wss_oam_token_client_policy in Oracle Web Services Manager.

About oracle/wss_oam_token_service_policy

This Oracle Web Services Manager policy contains the policy assertion oracle/wss_oam_token_service_template. This template uses the credentials in the WS-Security header's binary security token to authenticate users against the Oracle Access Manager identity store.

The Oracle Access Manager Identity Asserter uses the ObSSOCookie token to assert the identity of users who try to access a Web service protected by the oracle/wss_oam_token_service_policy policy. A Web service that is protected by this policy must be presented with an ObSSOCookie token in a SOAP header. That is, the Web service consumes the ObSSOCookie token; it is not involved in how the token is generated. Specifically, the WebLogic Server security service detects the token type and invokes the Oracle Access Manager Identity Asserter. The Oracle Access Manager Identity Asserter then validates the ObSSOCookie token against the Oracle Access Manager Access Server and obtains the username. The username is populated as the principal in the authenticated subject.

The Web service client, for example the Web application, must obtain the ObSSOCookie token to send it to the Web service. This is typically done using an AccessGate. AccessGate challenges the Web service client user for credentials (depending on the authentication scheme configured in Oracle Access Manager) and authenticates the user. The WebGate sends the ObSSOCookie to the user's browser upon successful authentication

The Web service client then sends the ObSSOCookie token in the SOAP request to the Web service.

About oracle/wss_oam_token_client_policy

This Oracle Web Services Manager policy contains the following policy assertion: oracle/wss_oam_token_client_template. This template inserts Oracle Access Manager credentials into the WS-Security header as part of the binary security token.

oracle/wss_oam_token_client_policy is the analogous client policy to the oracle/wss_oam_token_service_policy service endpoint policy. This policy can be enforced on any SOAP-based endpoint.

The following task overview outlines the procedures you must perform.

Task overview: Setting policies in Oracle Web Services Manager

1. Using Oracle Web Services Manager, set up a Web service with the oracle/wss_oam_token_service_policy policy.

2. Using Oracle Web Services Manager, set up a corresponding client for the Web service with the oracle/wss_oam_token_client_policy policy.

3. Configuring Providers in a WebLogic Domain for Oracle Web Services Manager.

9.4.4.3 Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several Authentication Providers must be configured and ordered in a WebLogic domain:

• OAM Identity Asserter: REQUIRED

• OID Authenticator: SUFFICIENT

• DefaultAuthenticator: SUFFICIENT

This procedure is nearly identical to the one for the Oracle Access Manager Identity Asserter. The difference in this case is that Oracle Web Services Manager requires a custom AccessGate and additional provider-specific values are required:

• Primary Access Server: Specify the host and part. For example: abcd:7777

• Access Gate Name: The name of the AccessGate protecting the application. For example: mmmm

• Access Gate Password: The AccessGate password as specified in the Access System Console.

You can add these using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

To set up providers in a WebLogic domain

1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

   1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      

   2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      

   3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      

2. Log in to the Oracle WebLogic Administration Console.

3. OAM Identity Asserter: Perform the following steps to add this provider:

   1. Click Security Realms, Default Realm Name, and click Providers.

   2. Click Authentication, click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

   3. In the Authentication Providers table, click the newly added authenticator.

   4. On the Common tab, set the Control Flag to REQUIRED, and click Save.

   5. Click Platform-Specific tab and configure these parameters:

      Primary Access Server: Specify the host and part. For example: abcd:7777

      Access Gate Name: The name of the AccessGate protecting the application. For example: mmmm

      Access Gate Password: The AccessGate password as specified in the Access System Console.

      Save

4. OID Authenticator: Perform the following steps to add this provider.

   1. Click Security Realms, Default Realm Name, and click Providers

   2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click OK.

   3. In the Authentication Providers table, click the newly added authenticator.

   4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

   5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)

      Note:

      Do not set the All Groups filter as the default works fine as is.

      Click Save.

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

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

   2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

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

   4. Click Save.

6. Reorder Providers:

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

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

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

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

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

9.4.6.1 Recommended Process for Configuring Logout

There are two steps in the Oracle-recommended approach to configuring logout:

• Configuring WebGate for Logout using the Sample Logout File

• Configuring Applications for Logout

<html>
<head>
<script language="javascript" type="text/javascript">

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);

    //vars to parse the querystring
    var params = new Array();
    var par = new Array();
    var val;

    if (origQueryString != null && origQueryString != "") {

        params = origQueryString.split("&");

        //search for end_url and redirect the user to this
        for (var i=0; i<params.length; i++) {

        par = params[i].split("=");

        if ("end_url" == par[0]) {

          endUrlVal = par[1];

        //check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
        if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {

          if (endUrlVal.substring(0,1) == "%")
            endUrlVal = "/" + endUrlVal.substring(3);

         //modify the end_url value now
           endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
         }
    //redirect the user to this URL
    window.location.href = endUrlVal;
         }
       }
   }
}
</script>
</head>

<body onLoad="handleLogout();">

<h3>You have been logged out<h3>

</body>
</html>

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

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

9.4.6.2 Alternative Process for Configuring Logout

Oracle does not recommend this method unless your application already has a custom logout page that you do not wish to change for any reason.

WebGate logs out of any request for a URL that has the string "logout." in it. Exception: Image files such as logout.gif and logout.jpg. This is the simplest way to integrate an application with OAM SLO. If your logout page begins with "logout." (for example, logout.jsp) then you do not need to do any thing.

If your logout page does not begin with "logout.", then you must add your logout URL to the WebGate LogOutUrls parameter. For instance: LogOutUrls = "/myapplication /customscript.jsp".

9.4.8.1 About Using IPv6

Oracle Fusion Middleware and Oracle Access Manager support Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6.) Among other features, IPv6 supports a larger address space (128 bits) than IPv4 (32 bits), providing an exponential increase in the number of computers that can be addressable on the Web.

9.4.8.2 Apache Bridge Failure: Timed Out

If you experience a failure of the Apache bridge, you might see a message stating that there is no back-end server available for connection. In this case, the connection times out.

The Oracle WebLogic Server might be down or there might be incorrect values set in mod_weblogic.

To recover from an Apache Bridge Failure

1. Check the Oracle WebLogic Server to ensure that it is available.

2. Confirm that host and port information is specified correctly in the WebGate's Web server httpd.conf. For example:

   ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
   

   <IfModule mod_weblogic.c>
                WebLogicHost yourHost.yourDomain.com
                  WebLogicPort yourWlsPortNumber
             </IfModule>
   

9.4.8.3 Authenticated User with Access Denied

It is possible that an authenticated user does not have access rights to the requested resource.

If a user login is inconclusive or invalid, the user can be authenticated but not recognized as authorized for the requested resource. In this case, no explicit error message states the issue. Instead, the user is prompted to log in again.

9.4.8.4 Browser Back Button Results in Error

After successful authentication, if you click the Back button in the browser window, you might get an error for access/oblix/apps/webgate/bin/webgate.so.

When form-based authentication is used, Oracle Access Manager creates a form login cookie that holds information about the requested resource. On successful authentication, the state of the cookie changes. When the user clicks the Back button, the login form appears. When re-posted, the form login cookie no longer holds redirection details.

The ObSSOCookie is also sent with the form login cookie.The ObSSOCookie is correctly checked. As the form login cookie state changes, the form-based authentication does not occur and the form action is considered as a request for the resource.

Solution

Retry the request using the original URL.

9.4.8.5 Cannot Reboot After Adding OAM and OID Authenticators

If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication Provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.

To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.

To ensure you can restart the WebLogic Server

1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).

2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

3. From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.

4. Select View Conditions for the Admins Role.

5. Add the group and click Save.

9.4.8.6 Client in Cluster with Load-Balanced WebGates

Out of the box, Oracle Access Manager does not support load balanced AccessGates; you must use a third-party load balancer.

Suppose you have two WebGates: WebGateA and WebGateB. You can use the OAMCfgTool to create the profile to be shared by the two WebGates.

If you have an Oracle Fusion Middleware Application installed you already have the OAMCfgTool. In this case, skip Step 1.

Solution:

1. No Oracle Fusion Middleware Application: Obtain the OAMCfgTool if you have no Oracle Fusion Middleware application installed.

   1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      

   2. Locate the OAMCfgTool ZIP file with Access Manager Core Components (10.1.4.3.0):

      oamcfgtool<version>.zip  
      

   3. Extract and copy oamcfgtool.jar to the computer hosting WebGate:

2. Log in to the computer for WebGateA (even if WebGate is not yet installed).

3. Change to the file system directory containing OAMCfgTool and run a command like the following one to create one AccessGate Profile to be shared by the two WebGates. For example:

   java -jar oamcfgtool.jar mode=CREATE app_domain=SharedA_B 
   app_agent_password=<WebGate_password> 
   cookie_domain=<preferred_http_cookie_domain>
   ldap_host=wxyz
   ldap_port=6633
   ldap_userdn=orcladmin
   ldap_userpassword=<ldap_userpassword>
   oam_aaa_host=abcd
   oam_aaa_port=7789
   oam_aaa_mode=cert
   log_file=OAMCfg_date.log
   log_level=INFO
   output_ldif_file=<LDIF_filename>
   

4. Review the information provided by the tool. For example, the parameters and values in Step 3 would provide the following information:

   Processed input parameters
   Initialized Global Configuration
   Successfully completed the Create operation.
    Operation Summary:
        Policy Domain  : SharedA_B
        Host Identifier: SharedA_B_WD
        Access Gate ID : SharedA_B_AG
   

   Note:

   • Perform Step 5 if you have WebGate installed.

   • Perform Step 6 if WebGate is not yet installed.

5. Output LDIF Created: Import the LDIF to write information to the directory server. Otherwise, skip this step.

6. WebGates Not Installed: Install WebGateA and WebGateB and specify the same values as you did when creating the profile (plus additional values to properly finish the installation).

7. Installed WebGates: Using output from the OAMCfgTool Create command, run the Oracle Access Manager configureWebGate tool to set up the WebGate. For example:

   1. Go to:

      WebGate_install_dir\access\oblix\tools\configureWebGate

      where WebGate_install_dir is the directory where WebGate is installed.

   2. Run the following command to configure the WebGate using values specified with OAMCfgTool and other values needed to finish the installation. For example:

      configureWebGate -i WebGate_install_dir -t WebGate SharedA_B_AG  
      -P WebGate_password
      -m <open|simple|cert>
      -h Access_Server_Host_Name
      -p Access_Server_Port
      -a Access_Server_ID
      -r Access_Server_Pass_Phrase (must be the same as the WebGate_password)
      -Z Access_Server_Retry count
      

      See Also:

      "Configuring AccessGates and WebGates" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager

   3. Repeat these steps to configure WebGateB.

8. Confirm Profile in the Access System Console: Perform the following steps to view or modify the WebGate profile.

   1. Log in to the Access System Console as a Master or Delegated Access Administrator. For example:

      http://hostname:port/access/oblix
      

      hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System Console.

   2. Click Access System Configuration, and then click AccessGate Configuration.

   3. Click the All button to find all profiles (or select the search attribute and condition from the lists) and then click Go.

   4. Click a WebGate's name to view its details.

   5. Click Cancel to dismiss the page without changes, or click Modify to change values as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

9. In the load balancer host identifiers, add host name variations for both WebGates: WebGateA and WebGateB.

9.4.8.7 Error 401: Unable to Access the Application

An error message like the following:

401 Authorization Required

This typically means that the Oracle Access Manager Authentication Provider is incorrectly configured. For a listing of correct configurations, see "Oracle Access Manager Authentication Provider Parameter List".

9.4.8.8 Error 403: Unable to Access the Application

An error message like the following:

403 Forbiden

This typically means that the post-authenticate actions are incorrectly configured in the policy domain. Under the policy domain's authentication success actions, ensure that you have set obmygroups and uid in the Return Attribute field (not in the Return Value field).

For more information, see "Configuring a Policy Domain for the Oracle Access Manager Authenticator".

9.4.8.9 Error 404: Not Found ... Anything Matching the Request URI

Generally, this error indicates that the server has not found anything matching the Request-URI. This message informs that the Oracle WebLogic Server is not able to find a resource.

There is no indication of whether the condition is temporary or permanent:

• If the server cannot make temporary or permanent information available to the client, the status code 403 (Forbidden) can be used.

• If, through some internally configurable mechanism, the server could state that an old resource is permanently unavailable and has no forwarding address, the 410 (Gone) status code should be used.

To recover from Error 404

Confirm that the resource is deployed on the Oracle WebLogic Server. For example, if the pattern is /private1/Hello, confirm that Hello is accessible on the server with private1 as the root.

9.4.8.10 Error Issued with the Action URL in Form Login Page

This issue occurs if Form Authentication scheme is not properly configured in Oracle Access Manager. However, this cannot occur if you use the OAMCfgTool to set up a policy domain. For example:

Symptoms include:

• The user name and password fields in the login form must match the details in the Form authentication scheme

• The credential_mapping filter must be specified correctly in the Form authentication scheme

• The login form action URL must be protected with a policy

• The login form action URL must match the Action value specified in the authentication scheme's challenge parameter

9.4.8.11 Error or Failure on Oracle WebLogic Server Startup

If the WebLogic Server user is not part of the administrator's group in Oracle Access Manager, Oracle WebLogic Server restart and Authentication Provider initialization can fail. In this case, one of the following messages might appear in the AdminServer.log in $DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log:

)<Failed ---- FatalError:InvalidSchemeMapping 
...
Authentication Failed.
...
Login failed.
...

Solution

1. Confirm that the implementation is using the Oracle-provided default login form.

2. Create a group named "Administrators" in the Oracle Access Manager Identity System, and include the Oracle WebLogic Server user.

   See Also:

   Oracle Access Manager Identity and Common Administration Guide

3. Login to Oracle WebLogic Server using the credentials of the user in the Administrators group defined within the Oracle Access Manager Identity System.

4. Restart the Oracle WebLogic Server.

9.4.8.12 JAAS Control Flag

If this flag is set to REQUIRED and any other parameter is set to an incorrect value, the server does not start.

To prevent this issue, ensure that the Oracle Access Manager Authentication Provider is properly configured while this parameter value is set to OPTIONAL. Only after you have validated proper behavior in this way, should you reset the control flag to REQUIRED.

For more information, see "Configuring Providers for the Authenticator in a WebLogic Domain".

9.4.8.13 Login Form is Shown Repeatedly Upon Credential Submission: No Error

This issue typically points to an incorrect user name or password. No error is shown.

Ensure that you are supplying the correct user name and password. The user login name must be the value of the attribute that is configured in the Form Login authentication scheme. For example, Challenge Parameter creds: userid.

9.4.8.14 Logout and Session Time Out Issues

When a user logs out, or a user session times out, the user should be challenged for reauthentication. However, the following might occur instead:

• Logout: After logging out, if the user attempts to access the application in the same browser window the application is still accessible without reauthenticating.

• Session Time Out: After a user session time out, the user is challenged to reauthenticate. However, if the user gives a different user ID he is granted the same privileges as the previous user.

The ObSSOCookie is still present. Some configuration must be done at the application level to kill the ObSSOCookie. For proper behavior, WebLogic application session time out values should be the same as WebGate session time out values.

If setting up an Identity Asserter in the WebLogic Application Console, the Web application using the Identity Asserter must have its auth-method set to CLIENT-CERT. For more information, see "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g".

9.4.8.15 Not Found: The requested URL or Resource Was Not Found

If you receive a message stating that the requested URL or resource was not found on this server, the reverse proxy Web server might not be forwarding requests to the Oracle WebLogic Server.

To ensure that the reverse proxy is forwarding requests to Oracle WebLogic Server

1. Locate the httpd.conf file on the reverse proxy WebGate Web server. For example:

   ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
   

2. Confirm the correct settings to forward requests to the correct host and port of the Oracle WebLogic Server:

   #httpd.conf
         <IfModule mod_weblogic.c>
           WebLogicHost <host>
             WebLogicPort yourWlsPortNumber
         </IfModule>
   
         <Location /request-uri-pattern>
            SetHandler weblogic-handler
         </Location>
   

9.4.8.16 Oracle WebLogic Server Fails to Start

If the Oracle WebLogic Server fails to start, you can take the following actions.

1. Determine whether the Oracle Access Manager Authentication Provider is the only provider configured in the Oracle WebLogic Server realm. If it is, continue with Step 2.

2. Confirm whether the Oracle Access Manager Authentication Provider is configured correctly and make any changes needed.

3. Determine whether the Oracle Access Manager Authentication Provider control flag is set to REQUIRED. In this case, perform the following steps:

   1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).

      Note:

      To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.

   2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

   3. From the WebLogic Administration Console, go to Security Realms, Your Realm, Roles and Policies, Global Roles.

   4. Select View Conditions for the Administrators (or other) role.

   5. Add the group and click Save.

9.4.8.17 Oracle ADF Integration and Cert Mode

Problem

WebGate configuration of cache directives might not be compatible with certain browser versions (specifically Internet Explorer v7) when accessing certain URLs that allow you to download Microsoft Office documents (.xls, .doc, and so on).

For example, suppose that you have an Excel workbook deployed along with an Oracle ADF application in an Oracle Access Manager Cert-based environment.

If the ADFDi component is trying to access two URLs, and trying the second URL first, a failure occurs regardless of the ADFDi client side code. It is not able to handle the redirect from Oracle Access Manager WebGate to the SSL enabled endpoint and fails with the following stack trace:

WebException: The request was aborted: Could not create SSL/TLS secure channel

If you attempt to access the workbook, and the following message appears:

Microsoft Office Excel cannot access the file 

The cause could be any of the following:

• The file name or path does not exist.

• The file is being used by another program.

• The workbook you are trying to save has the same name as a currently open workbook.

However, if the message appears when the URL to workbook is explicitly pasted to Internet Explorer v7 address bar it might be due to WebGate default Cache Directives.

WebGates have default Cache Directives (Pragma=no-cache and CacheControl=no-cache) that might cause a problem with Internet Explorer v7 when a URL to an .xls workbook is directly pasted into the browser's address bar.

Solution

If the message appears when the URL to workbook is explicitly pasted to Internet Explorer v7 address bar, Oracle recommends removing the cache directives from respective WebGate configuration pages in the Access System Console.

To remove cache directives from respective WebGate configurations

1. From the Access System Console, click the Access System Configuration tab.

2. Click AccessGate Configuration, click Go on the search page, and then click the link to the desired AccessGate configuration page.

3. On the Details for AccessGate page, click Modify.

4. On the Modify AccessGate page, locate Web Server Client label and clear the following fields:

   • CachePragmaHeader

   • CacheControlHeader

5. Click Save.

9.4.8.18 URL Rewriting and JSESSIONID

In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.

To avoid issues of a mismatch with Oracle Access Manager, you can create a policy for matching the URL with JSESSIONID. For this example, suppose the protected URL is:

/myapp/login

You can create a policy within the appropriate policy domain to match the URL with JSESSIONID.

To avoid issues matching a re-written URL

1. Go to the Policy Manager and log in. For example:

   http://Webserver:port/access/oblix
   

   where Webserver refers to computer that hosts the Policy Manager Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System.

2. Click Policy Manager., click My Policy Domains, and click the link to the desired policy domain.

3. Click the Policies tab, and then click Add.

   Fill in and save General details:

   Name: JSESSIONID Matching Policy

   Resource operation(s): Select all applicable HTTP operations

   Resource: Select the context root (create it if needed). For example: /myapp

   URL Pattern: login

   Click Save.

9.5.1.1 Oracle WebLogic Security Framework

Figure 9-19 illustrates the location of components in the Oracle WebLogic Security Framework, including the OSSO Identity Asserter. Additional details follow.

Figure 9-19 Location of OSSO Components in the Oracle WebLogic Security Framework

Description of "Figure 9-19 Location of OSSO Components in the Oracle WebLogic Security Framework"

At the top of the figure, Oracle HTTP Server is installed. This installation includes mod_weblogic and mod_osso, which are required to pass the identity token to the Providers and Oracle WebLogic Server. The Oracle WebLogic Server includes the partner application and the Identity Asserter (also known as the Identity Assertion Provider). The 10g OracleAS Single Sign-On server (OSSO Server), on the right side of the figure, communicates directly with the directory server and Oracle HTTP Server.

9.5.1.2 OSSO Identity Asserter Processing

Figure 9-20 illustrates the processing that occurs when you have OSSO implemented with the Identity Asserter. Additional details follow the figure.

Figure 9-20 OSSO Identity Asserter Processing

Description of "Figure 9-20 OSSO Identity Asserter Processing"

The first time a request for a protected resource arrives at the mid-tier Web server, the request is redirected to the 10g OracleAS Single Sign-On server, which requires user credentials For a certificate-based authentication, no login page is displayed. After the user has been successfully authenticated, all further requests from that user require only that the user identity be asserted by the OSSO Identity Asserter before the population of a JAAS Subject takes place. The Subject is consumed by the downstream applications.

For example, suppose you have an application residing on an Oracle WebLogic Server that is front-ended with the Oracle HTTP Server. The application is protected using resource mappings in the mod_osso configuration. This case is described in the following process overview.

Process overview: OSSO Identity Asserter

1. The user requests a protected application.

2. The Oracle HTTP Server intercepts the request and processes it using mod_osso to check for an existing, valid Oracle HTTP Server cookie.

3. If there is no valid Oracle HTTP Server cookie, mod_osso redirects to the OracleAS SSO Server, which contacts the directory during authentication.

4. After successful authentication mod_osso decrypts the encrypted user identity populated by the OSSO server and sets the headers with user attributes.

5. mod_weblogic completes further processing and redirects the request to the Oracle WebLogic Server.

6. The WebLogic security layer invokes providers depending on their settings and the order specified. For example: the security layer invokes the:

   • Identity Asserter, which makes the identity assertion based on retrieved tokens

   • Oracle Internet Directory Authenticator (OID Authenticator), which populates the Subject with necessary Principals

   See Also:

   "Consumption of Headers with OSSO Identity Asserter"

7. A response is sent to the user through the Oracle HTTP Server, and access to the application is granted.

9.5.1.3 Consumption of Headers with OSSO Identity Asserter

This topic describes the headers sent by Oracle HTTP Server and the tokens set in the header and the headers consumed by the OSSO Identity Asserter. If the application needs to use the JAAS subject, configure OSSO Identity Asserter.

Table 9-14 provides the list of headers set by Oracle HTTP Server (mod_osso and mod_weblogic). An application whose logic consumes the JAAS subject for identifying user information, should be configured to use the OSSO Identity Asserter. which uses the OracleAS SSO token type set in bold in the table (Proxy-Remote-User). The OSSO Identity Asserter looks for the Proxy-Remote-User header and asserts the user's identity. The follow up OID Authenticator populates the JAAS subject.

Applications that do not require the JAAS subject for identifying user information, can read the headers directly using the request.getHeader() API. Such applications are free to read any header they need. Headers with user info are Osso-User-Dn, Osso-User-Guid, and Proxy-Remote-User.

9.5.2.1 Configuring mod_weblogic

You can either edit the Oracle HTTP Server httpd.conf file directly or add mod_weblogic configuration in a separate file and include that file in httpd.conf.

The following procedure includes steps for two different Web server releases. Perform steps as needed for your deployment:

• OHS 11g ships with mod_wl_ohs.so. In this case, skip Step 1.

• OHS 10g does not ship with mod_weblogic (mod_wl_.so). If Oracle HTTP Server 10g is installed, start with Step 1 to copy mod_wl_20.so before configuration.

To install and configure mod_weblogic

1. Oracle HTTP Server 10.1.3: Copy mod_wl_20.so to the Oracle HTTP Server modules directory: For example:

   From: WL_HOME/wlserver_10.0/server/plugin/linux/i686

   To: ORACLE_HOME/ohs/modules

2. Locate the Oracle HTTP Server httpd.conf file. For example:

   Oracle HTTP Server 10.1.3:

   ORACLE_HOME/ohs/conf/httpd.conf
   

   Oracle HTTP Server 11g:

   ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
   

3. Verify that mod_weblogic configuration is in httpd.conf, either by inclusion of the appropriate configuration file or the configuration itself directly. For example, for Oracle HTTP Server 10g:

   LoadModule weblogic_module ${ORACLE_INSTANCE}/ohs/modules/mod_wl_20.so
   <IfModule mod_weblogic.c>
      WebLogicHost yourHost.yourDomain.com
        WebLogicPort yourWlsPortNumber
   </IfModule>
    
   <Location /request-uri-pattern>
      SetHandler weblogic-handler
   </Location>
   

9.5.2.2 Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4

The mod_osso module is an Oracle HTTP Server module that provides authentication to OracleAS applications. This module resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a user name and password once the user has logged into the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie.

The mod_osso module enables single sign-on for Oracle HTTP Server by examining incoming requests and determining whether the requested resource is protected. If it is, then it retrieves the Oracle HTTP Server cookie.

Under certain circumstances, you must register Oracle HTTP Server mod_osso using the 10.1.4 Oracle Identity Manager single sign-on registration tool (ssoreg.sh or ssoreg.bat). Table 9-15 provides a summary of parameters and values for this purpose. Running the tool updates the mod_osso registration record in osso.conf. The tool generates this file whenever it runs.

The following procedure includes a sample command to register mod_osso. Values for your environment will be different.

To register mod_osso

1. Go to the following 10.1.4 Oracle Identity Manager directory path:

   ORACLE_HOME/sso/bin/ssoreg
   

2. Run ssoreg with the following parameters and values for your environment. For example, on Unix, this might look like:

   ./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server  
   -config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788 
   -update_mode CREATE -remote_midtier -config_file \tmp\osso.conf
   

3. Verify that the module mod_osso of the required Oracle HTTP Server is registered.

4. Proceed to "Configuring mod_osso to Protect Web Resources".

9.5.2.3 Configuring mod_osso to Protect Web Resources

mod_osso redirects the user to the single sign-on server only if the URL you request is configured to be protected. You can secure URLs in one of two ways: statically or dynamically. Static directives simply protect the application, ceding control over user interaction to mod_osso. Dynamic directives not only protect the application, they also enable it to regulate user access.

For more information, see:

• Configuring mod_osso with Static Directives

• Protecting URLs and Logout Dynamically (without mod_osso)

//home.jsp

<%@ include file="ssodynauth.jsp" %>
<%
//page content goes here
%>

//ssodynauth.jsp

<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "0");
%>
<%
// Check for user
String ssoUser = null;
try
(
//ssoUser = request.getRemoteUser();
ssoUser = request.getUserPrincipal( ).getName( );
ssoUser = ssoUser.trim( );
 }
catch(Exception e)
{
ssoUser = null;
 }

// If user is not authenticated then generate
// dynamic directive for authentication
if((ssoUser == null) || (ssoUser.length() < 1))
{
response.sendError(499, "Oracle SSO");
return;
}%>

//logout.jsp
<%@page session="false"%>
<%
   response.setHeader("Osso-Return-Url", "http://my.oracle.com/");
   HttpSession session =  null;
   session = request.getSession();
   if (null != session )
   {
     // necessary for achieving SLO
     session.invalidate();
   }
   response.sendError(470, "Oracle SSO");
%>

9.5.2.4 Adding Providers to a WebLogic Domain for OSSO

You must add the OSSO Identity Asserter to a WebLogic domain. In addition to the OSSO Identity Asserter, Oracle recommends the following Authentication Providers:

• OSSO Identity Asserter

• DefaultAuthenticator

• OID Authenticator

You can add providers using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

The following procedure illustrates adding Authentication Providers using the Oracle WebLogic Administration Console. Before you begin, there is a condition to pay attention to:

Step 10: If your application requires the user in the same case as in Oracle Internet Directory (uppercase, lowercase, initial capitals), check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.

To add providers to your WebLogic domain for OSSO Identity Assertion

1. Log in to the WebLogic Administration Console.

2. OSSO Identity Asserter: Perform the following steps to add this to the domain:

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

   2. Select New under the Authentication Providers table.

   3. Enter a name for the new provider, select its type, and then click OK. For example:

      Name: OSSO Identity Asserter

      Type: OSSOIdentityAsserter

      Ok

   4. Click the name of the newly added provider.

   5. On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.

3. Default Authentication Provider:

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

   2. Click Default Authentication Provider.

   3. Set the control flag to OPTIONAL, and click Save

4. OID Authenticator: Perform the following steps to add this provider.

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

   2. Click New, and enter a name and type:.

      Name. OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click Save.

   3. Click the newly added authenticator to see the Settings page. Retain the default settings; do not change the Control Flag until you have verified that the Oracle Internet Directory configuration is valid.

      Note:

      If OID Authenticator is the only provider, ensure the WebLogic Server user account and its granted group memberships are created in Oracle Internet Directory. Otherwise the WebLogic domain does not start properly.

   4. Click the Provider Specific tab and specify the following required settings:

      Propagate Cause For Login Exception: Check

      Principal: LDAP administrative user. For example: cn=orcladmin

      Host: The Oracle Internet Directory hostname

      Use Retrieved User Name as Principal: Check

      Credential: LDAP administrative user password. For example: password

      Confirm Credential: For example: password

      Group Base DN: Oracle Internet Directory group search base

      User Base DN: Oracle Internet Directory user search base.

      Port: Oracle Internet Directory port

5. Reorder Providers: The order in which providers populate a subject with principals is significant and you might want to reorder the list of all providers in your realm and bring the newly added provider to the top of the list.

6. Save all configuration settings.

7. Stop and restart the Oracle WebLogic Server for the changes to take effect.

8. Log in to the WebLogic Administration Console:

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

   2. Select the Users and Groups tab to see a list of users and groups contained in the configured Authentication Providers.

      You should see usernames from the Oracle Internet Directory configuration, which implicitly verifies that the configuration is working.

      --If the Oracle Internet Directory instance is configured successfully, you can change the Control Flag.

      --If the Oracle Internet Directory authentication is sufficient for an application to identify the user, then choose the SUFFICIENT flag. SUFFICIENT means that if a user can be authenticated against Oracle Internet Directory, no further authentication is processed. REQUIRED means that the Authentication Provider must succeed even if another provider already authenticated the user.

9. Application Requires User in Same Case as in Oracle Internet Directory: Check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.

10. Save the changes.

11. Activate the changes and restart Oracle WebLogic Server.

12. Proceed with "Establishing Trust Between Oracle WebLogic Server and Other Entities".

9.5.2.5 Establishing Trust Between Oracle WebLogic Server and Other Entities

The Oracle WebLogic Connection Filtering mechanism must be configured for creating access control lists and for accepting requests from only the hosts where Oracle HTTP Server and the front-end Web server are running.

A network connection filter is a component that controls the access to network level resources. It can be used to protect resources of individual servers, server clusters, or an entire internal network. For example, a filter can deny non-SSL connections originating outside of a corporate network. A network connection filter functions like a firewall since it can be configured to filter protocols, IP addresses, or DNS node names. It is typically used to establish trust between Oracle WebLogic Server and foreign entities.

Connection Filter Rules: The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules in the Administration Console. When entering the filter rules on the Administration Console, enter them in the following format:

targetAddress localAddress localPort action protocols

Table 9-16 provides a description of each parameter in a connection filter.

The Connection Logger Enabled attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.

To configure a connection filter to allow requests from the host of the 11g Oracle HTTP Server

1. Log in to the Oracle WebLogic Administration Console.

2. Click Domain under Domain Configurations.

3. Click the Security tab, click the Filter tab.

4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

5. Specify the connection filter to be used in the domain:

   • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

   • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

6. Enter the appropriate syntax for the connection filter rules.

7. Click Save.

8. Restart the Oracle WebLogic Server.

9. Proceed to "Configuring the Application for the OSSO Identity Asserter".

9.5.2.6 Configuring the Application for the OSSO Identity Asserter

This topic describes how to create the application authentication method for the OSSO Identity Asserter.

Oracle WebLogic Server supports adding multiple auth-methods. If you are setting up an OSSO Identity Asserter in the WebLogic Application Console, the Web application using the OSSO Identity Asserter must have its auth-method set to CLIENT-CERT.

After deploying the application on the Oracle WebLogic Server, all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method for the appropriate realm, as described in the following procedure.

To edit web.xml for the OSSO Identity Asserter

1. Locate the web.xml file in the application EAR file. For example:

   WEB-INF/web.xml  
   

2. Locate the auth-method for the appropriate realm and enter CLIENT-CERT. For example:

   <login-config>
     <auth-method>CLIENT-CERT</auth-method>
     <realm-name>myRealm</realm-name>
   </login-config>
   

3. Save the file.

4. Redeploy and restart the application.

5. Repeat for each web.xml file in the application EAR file.

9.5.3.1 SSO-Related Problems

This section addresses the following troubleshooting items:

• OHS Is Not Redirecting to SSO - Internal Server Error 500

• Is Attribute AuthName Required?

• URL Request not Redirected to SSO

• Error 404 - Not Found is Issued (OHS Side)

• Error 404 - Not Found is Issued (Oracle WebLogic Server Side)

• Oracle SSO Failure - Unable to process request

• OSSO Solution for Applications Deployed on a Stand-alone WebLogic Server

OHS Is Not Redirecting to SSO - Internal Server Error 500

The most likely source of this problem is an incorrect configuration.

The following sample uses Oracle HTTP Server 11g. Path names are different if you have Oracle HTTP Server 10g.

To address it, proceed as follows:

1. Open the file mod_osso.conf and ensure that the resource is protected. For example:

   ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf  
   

   <Location /protected-resource-uri>
   require valid-user
   AuthType Basic
   </Location>
   

2. Ensure that osso.conf is present and included in mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g)

   OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf  
   

   Note:

   There is no set location for osso.conf. The value is determined at registration time; it can be any absolute path.

3. Ensure that httpd.conf includes mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g):

   ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
   

   include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
   

4. If all of the above were correctly specified, the SSO registration did not complete successfully and you must re-register SSO.

   To register SSO, proceed as follows using the appropriate ssoreg tool for your platform. For example:

   1. Run ssoreg.sh in 10.1.4 ORACLE_HOME/sso/bin to produce the file osso.conf. The following is a sample usage of this utility that produces the file in /tmp/osso.conf (the arguments are displayed in different lines only for illustration):

      >ssoreg.sh -oracle_home_path /OraHome 
                 -site_name wls_server 
                 -config_mod_osso TRUE 
                 -mod_osso_url http://host.domain.com:6666 
                 -update_mode CREATE 
                 -remote_midtier 
                 -config_file /tmp/osso.conf
      

   2. Copy the generated osso.confto another file system directory. For example: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso.

   3. Restart OHS.

Is Attribute AuthName Required?

Log messages might suggest that the attribute AuthName is required, and certain versions of Apache do require this attribute.

This example uses Oracle HTTP Server 11g. Path names are different for Oracle HTTP Server 10g.

To include this attribute, edit the file mod_osso.conf and insert a fragment like the following:

LoadModule osso_module modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
 
<Location />
AuthName "Oracle Single Sign On"
require valid-user
AuthType Basic
</Location>
</IfModule>

URL Request not Redirected to SSO

Once a URL request is issued, if a basic pop-up is displayed instead of being redirected to SSO, then, most likely, the URL request has been intercepted by the Apache authorization module.

To address this problem, proceed as follows:

1. Edit the file httpd.conf and comment out the loading authorization modules as illustrated in the following fragment:

   ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
   

   LoadModule access_module modules/mod_access.so
   #LoadModule auth_module modules/mod_auth.so
   #LoadModule auth_anon_module modules/mod_auth_anon.so
   #LoadModule auth_db_module modules/mod_auth_dbm.so
   LoadModule proxy_module modules/mod_proxy.so
   

2. Restart OHS.

Error 404 - Not Found is Issued (OHS Side)

Typically, this error has the following format:

The requested URL <request-uri> was not found on this server

Most likely, the WebLogic redirect is not happening, and the request is attempting to grab an OHS resource not available.

To address this problem, verify that mod_weblogic is included in the file httpd.conf and that the WebLogic handler is set for the request pattern, as illustrated in the following fragment:

#httpd.conf
<IfModule mod_weblogic.c> 
 WebLogicHost <host>
  WebLogicPort yourWlsPortNumber
</IfModule>
 
<Location /request-uri-pattern>
 SetHandler weblogic-handler
</Location>

Error 404 - Not Found is Issued (Oracle WebLogic Server Side)

Typically, this error has the following format:

Error 404--Not Found

Cause

This message informs that the Oracle WebLogic Server is not able to find a resource.

Solution

To address the problem, check that the resource is indeed deployed on the server. For example, if the pattern is /private1/Hello, check that Hello is accessible on the server with private1 as root.

Oracle SSO Failure - Unable to process request

Problem

You receive a message stating:

Oracle SSO Failure - Unable to process request
Either the requested URL was not specified in terms of a fully-qualified host
name or Oracle HTTP Server single sign-on is incorrectly configured.
Please notify your administrator. 

Solution

Modify the Oracle HTTP Server httpd.conf file to include a port number in the ServerName and restart the Web server. For example:

From: ServerName host.domain.com

To: ServerName host.domain.com:port

OSSO Solution for Applications Deployed on a Stand-alone WebLogic Server

This chapter describes how to configure single sign-on (SSO) for applications that are deployed on Oracle Fusion Middleware Oracle WebLogic Server. However, details for applications that are deployed on a stand-alone Oracle WebLogic Server (one without Fusion Middleware) are provided here:

• Oracle Fusion Middleware with OSSO: The required OSSO Identity Asserter (ossoiap.jar) is provided automatically when you install Oracle Fusion Middleware: Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter.

  Note:

  Oracle Fusion Middleware with OSSO enables you to use either the Oracle HTTP Server 10g or 11g Web server.

• Stand-Alone Oracle WebLogic Server with OSSO: The required OSSO Identity Asserter (ossoiap.jar) must be acquired from the Oracle Web Tier, as described here.

  Note:

  Without Fusion Middleware, OSSO requires Oracle HTTP Server 11g.

Whether you use OSSO for Oracle Fusion Middleware applications or other applications, the Identity Asserter performs the same functions as those illustrated and described in "Using the OSSO Identity Asserter".

Included in the following are additional, optional, details that you can use to configure and test Single Logout for session invalidation and synchronization between the SSO cookie and the JSESSIONID cookie. Required files must be acquired from the Oracle Web Tier.

Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server

1. Install Oracle WebLogic Server 10.3.1+ and other required components as follows:

   1. Perform Step 1, a-d as described in the "Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server".

   2. Skip Step 1e and instead deploy your application.

2. Create a WebLogic security domain with the weblogin domain extension template that is supplied with Oracle WebLogic Server and can be used from $WLS_HOME/common/bin/config.sh.

3. Configure mod_weblogic to forward requests to Oracle WebLogic Server, as explained in "Configuring mod_weblogic".

4. Register and configure the module mod_osso with the 10g SSO Server as a partner application, as described in "New Users of the OSSO Identity Asserter".

   1. Perform steps described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".

   2. Perform steps described in "Configuring mod_osso to Protect Web Resources".

5. Add Authentication Providers to the appropriate security domain as follows:

   1. Acquire the OSSO Identity Asserter (ossoiap.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar  
      

   2. Copy ossoiap.jar into $WLS_HOME/wlserver_10.x/server/lib/mbeantype, then restart the Oracle WebLogic Server.

   3. Configure providers as described in "Adding Providers to a WebLogic Domain for OSSO".

6. Configure the Oracle WebLogic Connection Filtering mechanism to create access control lists and accept requests from the hosts where Oracle HTTP Server and the front-end Web server are running, as explained in "Establishing Trust Between Oracle WebLogic Server and Other Entities".

   Note:

   Test the secured application to ensure that it is working with the default authenticator using the Oracle WebLogic Server host and port.

7. Configure the application authentication method for the OSSO Identity Asserter (all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method), as explained in "Configuring the Application for the OSSO Identity Asserter".

   Note:

   Test the application with users authenticated by OSSO while accessing the application with the Oracle HTTP Server host and port.

8. Optional: You can configure and test Single Logout [Session Invalidation and synchronization between the SSO cookie and JSESSIONID cookie] as follows:

   See Also:

   ""Synchronizing the User and SSO Sessions: SSO Synchronization Filter" for details on SSOFilter

   1. Acquire ssofilter.jar and configure Oracle WebLogic Server to use it as follows:

      1. Acquire ssofilter.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar  
      

      2. Copy it to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Add the absolute path of ssofilter.jar to the Oracle WebLogic Server classpath (by editing the setDomainEnv.sh script POST_CLASSPATH variable or CLASSPATH variable).

   2. Deploy system-filters.war as a system filter, as follows:

      1. Acquire system-filters.war from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war 
       
      

      2. Copy system-filters.war to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Deploy system-filters.war as an application library: From the WebLogic Administration Console, click Deployment, select New, and choose the location of file.

      4. Restart the Oracle WebLogic Server, if asked.

   3. Enable Logs to verify that the SSOFilter is working, as follows:

      1. From the WebLogic Administration Console, click Domain, Environment, Servers, AdminServer.

      2. Click the Logging tab.

      3. From the Advanced drop-down, select "Minimum Severity to Log" as "Debug".

      4. From the Advanced drop-down, "Message destinations", select LogFile: Severity Level as "Debug".

      5. Save changes and restart the Oracle WebLogic Server.

   4. Confirm that the SSOFilter is loaded as a system filter:

      1. Open the AdminServer.log file in DomainHome/Servers/AdminServer/log/AdminServer.log.

      2. Search for "SSOFilter" and confirm that you can see <Debug> messages, which indicate SSOFilter initialization nd confirm a filter load

   5. Test the filter functionality to confirm that the SSO and JSESSIONID cookie are cleaned up after user logout and that attempts to access the application after logout require another login.

      Note:

      You must have OSSO Identity Asserter configured in the WebLogic security domain, otherwise the filter will automatically disable during its initialization.

   6. Test logout with applications to confirm that the session is ends cleanly.

SSO Users Specified in "Users to Always Audit" Must Be Uppercase

When you specify SSO users in the Oracle HTTP Server audit configuration "Users to Always Audit" section, the SSO username must be specified in uppercase characters.

A comma-separated list of users can be specified to force the audit framework to audit events initiated by these users. Auditing occurs regardless of the audit level or filters that have been specified. This is true for all authentication types.

For more information, see "Managing Audit Policies" in the chapter "Configuring and Managing Auditing" in the Oracle Fusion Middleware Application Security Guide.

9.5.3.2 OSSO Identity Asserter-Related Problems

This section addresses the following troubleshooting items:

• Error 403 - Forbidden

• Error 401 - Unauthorized

• OSSO Identity Assertion Not Getting Invoked

Error 403 - Forbidden

This message informs that the user does not have the required permission to access a resource. This message is shown, for example, when the application has been configured to allow access to users belonging to WLS Group SSOUsers and the asserted user belongs to a different group.

If you have verified that this is not a permissions issue, then check whether the JAAS Control Flag for the Default Identity Authenticator is set to REQUIRED, and if so, change the setting to OPTIONAL or to SUFFICIENT, as appropriate.

Error 401 - Unauthorized

This message informs that the access to a resource requires the user to be first authenticated.

Solution

1. Check that the user is indeed authenticated.

2. Check whether the server is being hit without first going through authentication using SSO.

OSSO Identity Assertion Not Getting Invoked

Situations in which the OSSO Identity Asserter is not getting invoked for a protected source, typically, involve incorrect configuration. Make sure that your environment accurately includes a configuration as that described in "Configuring the Application for the OSSO Identity Asserter".

9.5.3.3 URL Rewriting and JSESSIONID

In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.

To avoid issues of a mismatch, you can append an asterisk, *, to the end of the protected resource specified in mod_osso.conf. For example, if the protected URL is:

/myapp/login

The location in the mod_osso entry would be:

<Location /myapp/login*>
valid user
AuthType OSSO
</Location>

9.5.3.4 About mod_osso, OSSO Cookies, and Directives

Mod_osso module provides communication between the SSO-enabled login server and the Oracle HTTP Server listener. The mod_osso module is controlled by editing the mod_osso.conf file:

• Oracle HTTP Server 11g installation includes mod_osso and mod_weblogic.

• OHS 10g, available in the companion CD release Oracle HTTP Server 10.1.3, includes mod_osso.

  See Also:

  The following topic and Release 1 (11.1.1) manuals

  • "Configuring mod_osso to Protect Web Resources"

  • Oracle Fusion Middleware Installation Guide for Web Tier

  • Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

This section provides the following information:

• New OssoHTTPOnly Directive in mod_osso

• OssoSecureCookies Directive in mod_osso

• Mod_osso Does Not Encode the Return URL When Redirecting to OSSO for Logout

<VirtualHost *.7778> 
OssoConfigFile  conf/osso.conf
OssoHTTPOnly On
---
---
---
<Location /osso>
AuthType Osso
---
---
</Location> 

</VirtualHost> 

ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

OssoSecureCookies "Off"

9.5.3.5 About Using IPv6

Oracle Fusion Middleware supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6.) Among other features, IPv6 supports a larger address space (128 bits) than IPv4 (32 bits), providing an exponential increase in the number of computers that can be addressable on the Web.