Skip Headers
Oracle® Fusion Middleware Application Security Guide
11g Release 1 (11.1.1)

Part Number E10043-11
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

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

16 Configuring Single Sign-On with Oracle Access Manager 11g

The chapter provides information on configuring single sign-on using Oracle Access Manager 11g. It includes the following major sections:

16.1 Introduction to Oracle Access Manager 11g SSO

Oracle Access Manager 11g is part of Oracle's enterprise class suite of security products. Intended for use in new and existing SSO deployments, Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration, and more.

Oracle Access Manager 11g single sign-on (SSO) and single log-out (SLO) supports a variety of application platforms including:

Oracle Access Manager 11g supports integration with a variety of applications, as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.

As described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service, Oracle Access Manager 11g differs from Oracle Access Manager 10g in that identity administration features have been transferred to Oracle Identity Manager 11g. This includes user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration.

Console Protection for Oracle Identity Management Applications

Oracle Access Manager 11g and other Oracle Identity Management applications are deployed on a WebLogic container. Individual administration consoles include Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Identity Navigator, Oracle Identity Manager, Oracle WebLogic Server, and Oracle Entitlements Server.

These are protected by default using pre-configured Authentication Providers in the WebLogic Administration Console and a pre-registered IAMSuiteAgent with Oracle Access Manager 11g. OAM 11g SSO policies are pre-seeded. No further configuration is needed for the consoles.

Preview of OAM 11g Deployments

You can configure Oracle Access Manager in a new WebLogic administration domain or in an existing WebLogic administration domain using the Oracle Fusion Middleware Configuration Wizard.

See "Requirements for the Provider with Oracle Access Manager".

Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with new or existing policy-enforcement agents. Dynamic Server-initiated updates are performed for any policy or configuration changes.

Oracle Access Manager 11g provides single sign-on (SSO), authentication, authorization, and other services to registered Agents (in any combination) protecting resources:

You can integrate with Oracle Access Manager 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework.

Only users with sufficient privileges can log in to the Oracle Access Manager Administration Console or use OAM administrative command-line tools. Your enterprise might require independent sets of administrators: one set of users responsible for OAM administration and a different set for WebLogic administration. For more information, see "Defining a New OAM Administrator Role" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Overview of OAM 11g

The following outlines some of the basic features of Oracle Access Manager 11g:

Provisioning/Remote Registration: A new remote registration tool enables administrators inside or outside the network to register agents and policies. A username and password must be set in the primary User Identity Store for OAM 11g.

Authentication: Oracle Access Manager 11g application domains aggregate resources and security policies (one policy per resource). Oracle Access Manager 11g authentication policies include a specific scheme. Supported authentication modules include LDAP, X.509, and Kerberos. Authentication user mapping is performed against the primary user-identity provider by the centralized credential collector.

Authorization: Oracle Access Manager 11g performs authorization based on security policies defined in the application domain and persisted in the database. Authorization policies define the resource and constraint evaluation.

Responses: Administrators can set session attributes using authentication and authorization Responses. Aside from session attributes, a Response can also obtain user-related data and request-related data. Responses, once set, are then sent as either HTTP Headers or Cookies to the agent that helps manifest them. For cookie values and header variables, Responses can retrieve session attributes previously set by another Response. For example, session attributes set by a Response upon authentication can be retrieved as a header value during authorization.

Session Management: Oracle Access Manager 11g session management services track active user sessions through a high performance distributed cache system based on technology from Oracle Coherence. Each Oracle Access Manager runtime instance is a node within the distributed cache system. Secure communication between the nodes is facilitated using a symmetric key. The Oracle Access Manager runtime instances move user session data in the local cache into the distributed cache for other nodes to pick up. Each Oracle Access Manager runtime instance can also configure the replication factor and determine how session data is distributed. Administrators can configure the session lifecycle, locate and remove specific active sessions, and set a limit on the number of concurrent sessions a user can have at any time. Out-of-band session termination prevents unauthorized access to systems when a user has been terminated.

Keys: The Oracle Access Manager 11g runtime is deployed as an application to a WebLogic Managed Server or Cluster. New Oracle Access Manager 11g WebGates support a shared secret per agent trust model. 11g WebGates use agent/host specific cookies, which offers superior security. Oracle Access Manager 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf. Cookie-replay types of attacks are prevented.

SSO and SLO: The Oracle Access Manager 11g Server Session Token forms the basis for SSO between Oracle Access Manager and OSSO Agents. Logout is driven through Oracle Access Manager 11g Server Global Logout, which terminates the central session and logs out the user from each agent that was visited.

Logging and Auditing: Oracle Access Manager 11g components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. Oracle Access Manager 11g provides agent and server monitoring functions. Oracle Access Manager 11g auditing functions are based on the Common Audit Framework; audit-report generation is supported using Oracle Business Intelligence Publisher.

Access Tester: The new Oracle Access Manager 11g Access Tester enables IT professionals and administrators to simulate interactions between registered Oracle Access Manager Agents and Servers. This is useful when testing security policy definitions or troubleshooting issues involving agent connections.

Transition from Test to Production: Oracle Access Manager 11g enables moving configuration or policy data from one Oracle Access Manager 11g deployment to another (from a small test deployment to a production deployment, for example). Support for the creation of new topologies is based on templates. You can also copy and move policy changes.

Co-existence and Upgrades for OSSO 10g: The Oracle-provided Upgrade Assistant scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and transfers configured partner applications into the destination Oracle Access Manager 11g SSO.

See Also:

16.1.1 Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate

This topic is required for only 10g custom AccessGates. Skip this topic if it does not apply to your environment.

The Application Authenticator application domain is delivered with OAM 11g. It is pre-seeded with the policy objects that enables integration with applications deployed on WebLogic environments using the OAM Authentication Provider as the security provider. It is not associated with WebGate provisioning. When you provision a WebGate or AccessGate to use this (or another existing application domain), you will decline having policies created automatically.

The Application Authenticator application domain comes into play with the custom 10g AccessGate used with the OAM Authenticator (and the Identity Asserter for Oracle Web Services Manager). In this case, the custom AccessGate (not WebGate) contacts the WebLogic Server directly with a token to authenticate the user before OAM 11g is contacted.

The Application Authenticator application domain protects only resources of type wl_authen and is seeded with two authentication policies and one authorization policy. The following wl_authen resources are also seeded in this domain:

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion protected by LDAPNoPasswordValidationScheme

Note:

Only resources of type wl_authen are allowed in this domain; no other resource types can be added. Policies and Responses for wl_authen resources can be added. However, ideally, you will not need to modify this domain.

Figure 16-1 illustrates details of the seeded Application Authenticator application domain in the OAM 11g Administration Console. The page shown describes the pre-seeded User ID Assertion authentication policy, which protects the /Authen/UsernameAssertion resource. The authentication scheme for this policy is also shown along with the resources that are protected by the policy.

Figure 16-1 Pre-seeded Resources in the User ID Assertion Authentication Policy

Surrounding text describes Figure 16-1 .

Figure 16-2 illustrates pre-seeded Responses for the User ID Assertion authentication policy. For more information about Responses, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Figure 16-2 Pre-seeded Responses in the User ID Assertion Policy

Surrounding text describes Figure 16-2 .

Figure 16-3 illustrates the pre-seeded Application SSO authentication policy, the resources protected by this policy, and the authentication scheme.

Figure 16-3 Pre-seeded Application SSO Authentication Policy and Resources

Surrounding text describes Figure 16-3 .

Figure 16-4 illustrates Pre-seeded Responses for the Application SSO authentication policy in the application domain.

Figure 16-4 Pre-seeded Responses for the Application SSO Authentication Policy

Surrounding text describes Figure 16-4 .

Figure 16-5 illustrates the pre-seeded Application SSO authorization policy and Resources in the application domain.

Figure 16-5 Pre-seeded Application SSO Authorization Policy and Resources

Surrounding text describes Figure 16-5 .

Authorization Constraints: There are no pre-seeded Application SSO authorization policy Constraints in this application domain. However, you can add constraints as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Authorization Responses: There are no pre-seeded Application SSO authorization policy Responses in the application domain. However, you can add responses as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.2 Deploying the Oracle Access Manager 11g SSO Solution

This section introduces how to implement OAM 11g with the Authentication Provider when you have applications that are (or will be) deployed on a WebLogic container.

This section provides the following topics to help you implement OAM 11g SSO when you have applications deployed on a WebLogic container. Aside from these uniquely OAM 11g methods, implementing OAM solutions are the same whether you have OAM 11g or OAM 10g:

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for details about the scenario for Identity Propagation with the OAM Token.

16.2.1 Installing the Authentication Provider with Oracle Access Manager 11g

The following overview outlines the tasks that must be completed to install the required components and files for the Oracle Access Manager 11g SSO solution using the Authentication Provider. While many of these tasks are nearly the same for Oracle Access Manager 11g and Oracle Access Manager 10g, there are a few differences.

Task overview: Installing components for use with the Authentication Provider and OAM 11g

  1. Install and set up Oracle Internet Directory for Oracle Access Manager.

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

  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.

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

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

      WebGate: For identity assertion with the OAM Identity Asserter, a perimeter Webgate is required (installed and configured) on the OHS Web Server.

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

  5. Authentication Provider Files: Confirm the required JAR and WAR files as follows:

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

      $ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
      
    2. Locate the console-extension WAR file in the following path:

      $ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamauthenticationprov 
      ider.war
      
    3. Copy the WAR file to the following path in the WebLogic Server home:

      $WLS_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
      
  6. Oracle Access Manager 11g:

    1. Install Oracle Access Manager and perform initial configuration.

    2. Trusted Header Assertion: Go to My Oracle Support, retrieve the latest Bundle Patch, and apply it as described in the companion readme file: http://support.oracle.com.

  7. AccessGate for the Authenticator (or for Oracle Web Services Manager):

16.2.2 Converting Oracle Access Manager Certificates to Java Keystore Format

Oracle recommends that all Java components and applications use JKS as the keystore format. This topic provides steps to convert Oracle Access Manager X.509 certificates to Java Keystore (JKS) format. These steps, when followed properly, generate the JKS stores that can be used while the Java NAP client wants to communicate with an OAM Server in Simple or Cert (certificate) mode.

Note:

This procedure is required regardless of the SSO mechanism you choose.

When communicating in Simple or Cert mode, the OAM Server uses a key, server certificate, and CA chain files:

  • aaa_key.pem: the random key information generated by the certificate-generating utilities while it sends a request to a Root CA. This is your private key. The certificate request for WebGate generates the certificate-request file aaa_req.pem. You must send this WebGate certificate request to a root CA that is trusted by the OAM Server. The root CA returns the WebGate certificates, which can then be installed either during or after WebGate installation.

  • aaa_cert.pem: the actual certificate for the OAM Server, signed by the Root CA.

  • aaa_chain.pem: the public certificate of the Root CA. This is used when peers communicating in Simple or Cert mode perform an SSL handshake and exchange their certificates for validity. In Simple Mode, the aaa_chain.pem is the OpenSSL certificate located inOAMServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pem

Here, aaa is the name you specify for the file (applicable only to Cert and chain files).

You can edit an existing certificate with a text editing utility to remove all data except that which is contained within the CERTIFICATE blocks. You then convert the edited certificate to JKS format, and import it into the keystore. Java keytool does not allow you to import an existing Private Key for which you already have a certificate. You must convert the PEM format files to DER format files using the OpenSSL utility.

To convert an Oracle Access Manager certificate to JKS format and import it

  1. Install and configure Java 1.6 or the latest version.

  2. Copy the following files before editing to retain the originals:

    • aaa_chain.pem

    • aaa_cert.pem

    • cacert.pem, only if configuring for Simple mode

  3. Edit aaa_chain.pem using TextPad to remove all data except that which is contained within the CERTIFICATE blocks, and save the file in a new location to retain the original.

    -----BEGIN CERTIFICATE-----
    ...
    CERTIFICATE
    ...
    -----END CERTIFICATE-----
    
  4. Run the following command for the edited aaa_chain.pem:

    JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore 
    rootcerts
    

    Here you are assigning an alias (short name) root_ca to the key. The input file aaa_chain.pem is the one that you manually edited in step 3. The keystore name is rootcerts.

    You must give a password to access the keys stored in the newly created keystore.

    Note:

    To ensure security, Oracle recommends that you allow the keytool to prompt you to enter the password. This prompt occurs automatically when the "-storepass" flag is omitted from the command line.

  5. Enter the keystore password, when asked. For example:

    Enter keystore password: <keystore_password>
    Re-enter new keystore password: <keystore_password>
    
  6. Enter Yes when asked if you trust this tool:

    Trust this certificate? [no]: yes
    
  7. Confirm that the certificate has been imported to the JKS format by executing the following command and then the password.

    JDK_HOME\bin\keytool" -list -v -keystore "rootcerts"
    Enter keystore password: <keystore_password>
    
  8. Look for a response like the following:

    Keystore type: JKS
    Keystore provider: SUN
    Your keystore contains n entries
    Alias name: root_ca
    Creation date: April 19, 2009
    Entry type: trustedCertEntry
    
    Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California , C=US
    
    Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California ,C=US
    
    Serial number: x
    Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57
    GMT+05:30 2010
    
    Certificate fingerprints
      MD5:  CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC
      SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95
      Signature algorithm name: MD5withRSA
      Version: 1
    *******************************************
    
  9. Repeat steps 3 through 7 for the other PEM files (except aaa_chain.pem unless there is a chain).

  10. Convert the aaa_key.pem file to DER format using the OpenSSL utility in the OAM Server installation directory path. For example:

    $OAM_SERVER_HOME\access\oblix\tools\openssl>openssl pkcs8 -topk8  
    -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER 
    

    Here the input file is aaa_key.pem and the output file is aaa_key.der. Additional options include:

    Table 16-1 Options to Create DER Format Files from PEM

    Option Description

    -topk8

    Reads a traditional format private key and writes a PKCS#8 format key. This reverses the default situation where a PKCS#8 private key is expected on input and a traditional format private key is written.

    -nocrypt

    An unencrypted PrivateKeyInfo structure is expected for output.

    -inform

    Specifies the input format. If a PKCS#8 format key is expected on input, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used.

    -outform

    Specifies the output format. If a PKCS#8 format key is expected on output, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used.


  11. Simple or Cert Mode: In the PEM file (in this case, aaa_cert.pem), enter the pass phrase for the OAM Server if it is configured for Simple or Cert mode.

    Passphrase for the certificate
    
  12. Run the following command to convert the aaa_cert.pem file to DER format.

    AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in  
    aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
    
  13. Import the DER format files into a Java keystore using the ImportKey utility. For example:

    Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der   
    aaa_cert.der
    
  14. Review the results in the window, which should look something like the following example:

    Using keystore-file : jkscerts
    One certificate, no chain
    Key and certificate stored
    Alias:importkey  Password:your_password 
    

16.2.3 Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header assertion or clear text header mechanism, skip this topic.

Provisioning is the process of registering an agent and creating an application domain to use OAM 11g authentication and authorization services.You must provision a WebGate with OAM 11g whether you are preparing to install a fresh 11g or 10g instance or you have a legacy 10g WebGate installed.

The term WebGate is used for WebGates (and for the custom 10g AccessGates used with the Authenticator and the Identity Asserter for Oracle Web Services Manager). Unless explicitly stated, topics apply equally to both.

When you have multiple agents, each one can be provisioned independently or you can use a single OAM Agent registration for multiple agents.

Note:

The Application Authenticator application domain is pre-seeded and delivered with OAM 11g. When you provision an OAM Agent to use this (or another existing) application domain, decline the option of having policies automatically created.

The following topics are provided:

16.2.3.1 About WebGate Provisioning Methods for Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

Table 16-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.

Table 16-2 Provisioning Methods for OAM 11g

Method Description

Oracle Access Manager Administration Console

Enables OAM Administrators to manually 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.

Remote Registration

Application administrators who are implementing the Identity Asserter for single sign-on, can register the WebGate using the command line. This also creates a new application domain with security policies for a fresh or existing Web Tier.

Required parameters are provisioned using values for your environment specified in a template. Default values are accepted for non-required parameters. After registration, values can be modified in the Oracle Access Manager Console.


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

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for a complete list of WebGate parameters

Table 16-3 Required Registration Details for OAM Agents

OAM Agent Element Description

<serverAddress>

Points to a running instance of the Oracle Access Manager Administration Console, including the host and port.

<webDomain>

OSSO requests only

Defines the Web server domain under which the Agent Base URL is stored internally.

<agentName>

Defines a unique identifier for the agent on the OAM (Administration) Server.

For every agent on the same server instance, this tag must be unique to avoid re-registering the same agent.

Re-registering an agent on the same server instance is not supported.

<hostIdentifier>

This identifier represents the Web server host. The field is filled in automatically when you specify a value for the OAM Agent Name. If the agent name or host identifier of the same name already exists, an error occurs during registration.

<protectedResourcesList>

Specifies the resource URLs that you want the OAM Agent to protect with some authentication scheme. The resource URLs should be relative paths to the agentBaseUrl.

<publicResourcesList>

Specifies the resource URLs that you want to keep public (not protected by the OAM Agent). The resource URLs should be relative paths to the agentBaseUrl. For instance, you might want to specify the Home page or the Welcome page of your application


16.2.3.2 Provisioning a WebGate with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

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.

Note:

When provisioning an OAM 11g WebGate, use the OAM11gRequest_short.xml template.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service

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 with Oracle Security Token Service:


      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: OAM 11gRequest.xml

      To: my-wl-agent1.xml

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

      <OAMRegRequest>
          <serverAddress>http://sample.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 with Oracle Security Token Service

  3. Register the agent as follows:

    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 Oracle Access Manager Console and review the new registration:

    1. From the OAM 11g Console System Configuration tab, Access Manager Settings section, expand the SSO Agents nodes to search for the agent you just provisioned:


      Access Manager Settings
      SSO Agents
      OAM Agents
      Search
    2. In the Search Results table, 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 Oracle Access Manager Console, System Configuration tab, Common Configuration section, open 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:

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

This section describes the unique steps needed to configure Oracle Access Manager 11g Identity Assertion for Single Sign-On with your application.

Task overview: Deploying the Identity Asserter for SSO with OAM 11g includes

  1. Finishing all prerequisite tasks for the mechanism you are implementing:

  2. Establishing Trust with Oracle WebLogic Server

  3. Configuring Providers in the WebLogic Domain

  4. Trusted Header Assertion: Configuring Digital Signature Verification

  5. Trusted Header Assertion: Configuring Policies

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

  7. Synchronizing the User and SSO Sessions: SSO Synchronization Filter

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

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

Task overview: Establishing Trust with Oracle WebLogic Server

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

  2. Confirming mod_weblogic for Oracle Access Manager Identity Asserter

  3. Clear Text Header: Establishing Trust between Oracle WebLogic Server and Other Entities

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

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

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

You can add comma separated values here when you want applications accessed directly over the WebLogic Server host:port to be authenticated by the container. For instance: <auth-method>CLIENT-CERT,FORM</auth-method>.

The auth-method can use BASIC, FORM, or CLIENT-CERT 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 specify authentication in web.xml for the Identity Asserter

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

    my_app/WEB-INF/web.xml  
    
  2. Locate the auth-method in login-config and enter CLIENT-CERT.

    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>
    
  3. Save the file.

  4. Redeploy and restart the application.

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

  6. Proceed to "Confirming mod_weblogic for Oracle Access Manager Identity Asserter".

16.2.4.1.2 Confirming mod_weblogic for Oracle Access Manager Identity Asserter

Oracle Oracle HTTP Server includes the mod_weblogic plug-in module (mod_wl_ohs.so in 11g) which is already enabled. You can perform the following procedure to confirm this or skip this procedure.

With Oracle HTTP Server 11g, the mod_weblogic configuration is present in mod_wl_ohs.conf by default, and the path of this file is included in httpd.conf. If the mod_weblogic configuration is not present then you must edit httpd.conf.

To configure mod_weblogic for the Oracle Access Manager Identity Asserter

  1. Locate httpd.conf. For example:

    $ORACLE_HOME/config/OHS/<ohs_name>/httpd.conf
    
  2. Confirm that the following statement is in the file with appropriate values for your deployment (add or uncomment this, if needed):

    <IfModule mod_weblogic.c>
       WebLogicHost myHost.myDomain.com
         WebLogicPort myWlsPortNumber
    </IfModule>
     
    <Location http://request-uri-pattern>
       SetHandler weblogic-handler
    </Location>
    
  3. Save the file.

  4. Proceed as needed for your implementation:

16.2.4.1.3 Clear Text Header: 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.

Note:

This filter is required for security when you use Identity Assertion with the Clear Text Header mechanism. This task is optional when you use one of the other mechanisms.

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.

To configure a connection filter to allow requests from only mod_weblogic and the host where OHS 11g is running, perform the procedure here.

Note:

This chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs; the actual binary name is mod_wl_ohs.so. Examples show exact syntax for implementation.

WebLogic Server provides a default connection filter: weblogic.security.net.ConnectionFilterImpl. This filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.

You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.

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 16-4 provides a description of each parameter in a connection filter.

Table 16-4 Connection Filter Rules

Parameter Description

target

Specifies one or more systems to filter

localAddress

Defines the host address of the WebLogic Server instance. (If you specify an asterisk (*), the match returns all local IP addresses.)

localPort

Defines the port on which the WebLogic Server instance is listening. (If you specify an asterisk, the match returns all available ports on the server.)

action

Specifies the action to perform. This value must be allow or deny

protocols

Is the list of protocol names to match. The following protocols may be specified: http, https, t3, t3s, giop, giops, dcom, ftp, ldap. If no protocol is defined, all protocols match a rule.


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.

See Also:

"Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server

To configure a connection filter to allow requests from Oracle HTTP Server host

  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 Providers in the WebLogic Domain".

16.2.4.2 Configuring Providers in the WebLogic Domain

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

16.2.4.2.1 About Oracle WebLogic Server Authentication and Identity Assertion Providers

This topic introduces only a few types of Authentication Providers for a WebLogic security realm, if you are new to them.

Each WebLogic security realm must have at least one Authentication Provider configured. The WebLogic Security Framework is designed to support multiple Authentication Providers (and thus multiple LoginModules) for multipart authentication. As a result, you can use multiple Authentication Providers as well as multiple types of Authentication Providers in a security realm. The Control Flag attribute determines how the LoginModule for each Authentication Provider is used in the authentication process.

Oracle WebLogic Server offers several types of Authentication and Identity Assertion providers including, among others:

  • The default WebLogic Authentication Provider (Default Authenticator) allows you to manage users and groups in one place, the embedded WebLogic Server LDAP server. This Authenticator is used by the Oracle WebLogic Server to login administrative users.

  • Identity Assertion uses token-based authentication; the Oracle Access Manager Identity Asserter is one example. This must be configured to use the appropriate action for the installed WebGate (either 10g or 11g).

  • LDAP Authentication Providers store user and group information in an external LDAP server. They differ primarily in how they are configured by default to match typical directory schemas for their corresponding LDAP server.

    Oracle WebLogic Server 10.3.1+ provides OracleInternetDirectoryAuthenticator.

When you configure multiple Authentication Providers, use the JAAS Control Flag for each provider to control how the Authentication Providers are used in the login sequence. While there are other settings, you can use the following the JAAS Control Flag settings for this situation:

  • REQUIRED—The Authentication Provider is always called, and the user must always pass its authentication test. Regardless of whether authentication succeeds or fails, authentication still continues down the list of providers.

  • SUFFICIENT—The user is not required to pass the authentication test of the Authentication Provider. If authentication succeeds, no subsequent Authentication Providers are executed. If authentication fails, authentication continues down the list of providers.

  • REQUISITE—This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, return control to the application.

  • OPTIONAL—The user is allowed to pass or fail the authentication test of this Authentication Provider. However, if all Authentication Providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

When additional Authentication Providers are added to an existing security realm, the Control Flag is set to OPTIONAL by default. You might need to change the setting of the Control Flag and the order of providers so that each Authentication Provider works properly in the authentication sequence.

See Also:

"Configuring Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server for a complete list of Authentication Providers and details about configuring the Oracle Internet Directory provider to match the LDAP schema for user and group attributes

16.2.4.2.2 About the Oracle WebLogic Scripting Tool (WLST)

This topic introduces WLST, if you are new to it.

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

WLST is a Jython-based command-line scripting environment that you can use to manage and monitor WebLogic Server domains. Generally, you can use this tool online or offline. You can use this tool interactively on the command line in batches supplied in a file (Script Mode, where scripts invoke a sequence of commands without requiring your input), or embedded in Java code.

When adding Authentication Providers to a WebLogic domain, you can use WLST online to interact with an Authentication Provider and add, remove, or modify users, groups, and roles.

When you use WLST offline to create a domain template, WLST packages the Authentication Provider's data store along with the rest of the domain documents. If you create a domain from the domain template, the new domain has an exact copy of the Authentication Provider's data store from the domain template. However, you cannot use WLST offline to modify the data in an Authentication Provider's data store.

Note:

You cannot use WLST offline to modify the data in an Authentication Provider's data store.

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

On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Oracle Access Manager Single Sign On (SSO), and uses Oracle Platform Security Services (OPSS) SSO for user authentication. However before the Web application can be run, you must configure the domain-level jps-config.xml file on the application's target Oracle WebLogic Server for the Oracle Access Manager security provider.

The domain-level jps-config.xml file is in the following path and should not be confused with the deployed application's jps-config.xml file:

$DOMAIN_HOME/config/fmwconfig/jps-config.xml 

You can use an Oracle Access Manager-specific OPSS script to configure the domain-level jps-config.xml file, either before or after the Web application is deployed. This OPSS script is named as follows:

Linux: wlst.sh

Windows: wlst.cmd

The script is available in the following path if you are running through JDev:

$JDEV_HOME/oracle_common/common/bin/

In a WebLogic installation, the path is:

$MW_HOME/oracle_common/wlst

Note:

The script is required. When running WLST, do not use the script under $JDEV_HOME/wlserver_10.3/common/bin.

Command Syntax

addOAMSSOProvider(loginuri, logouturi, autologinuri)

Table 16-5 defines the expected value for each argument in the addOAMSSOProvider command line.

Table 16-5 addOAMSSOProvider Command-line Arguments

Argument Definition

loginuri

Specifies the URI of the login page

Note: For ADF security enabled applications, "/<context-root>/adfAuthentication" should be provided for the 'loginuri' parameter. Here is the flow:

  1. User accesses a resource that has been protected by authorization policies in OPSS, fox example.

  2. If the user is not yet authenticated, ADF redirects the user to the URI configured in 'loginuri'.

  3. Access Manager, should have a policy to protect the value in 'loginuri': for example, "/<context-root>/adfAuthentication.

  4. When ADF redirects to this URI, Access Manager displays a Login Page (depending on the authentication scheme configured in Access Manager for this URI).

autologinuri

Specifies the URI of the autologin page. For example: autologinuri="/obrar.cgi".

logouturi

Specifies the URI of the logout page

Note: For ADF security enabled applications, logouturi should be configured based on logout guidelines in Chapter 19 of Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service. For the:

  • 11g Webgate the value of the logouturi should be sought from the 11g Webgate Administrator.

  • 10g Webgate requires a logouturi value of /oamsso/logout.html.


Prerequisites

Configuring Providers in the WebLogic Domain

To modify domain-level jps-config.xml for a Fusion Web application with Oracle ADF Security enabled

  1. On the computer hosting the Oracle WebLogic Server and the Web application using Oracle ADF security, locate the OPSS script. For example:

    cd $ORACLE_HOME/oracle_common/common/bin
    
  2. Connect to the computer hosting the Oracle WebLogic Server:

    connect login_id password hostname:port
    

    For example, the Oracle WebLogic Administration Server host could be localhost using port 7001. However, your environment might be different.

  3. Enter the following command-line arguments with values for the application with ADF security enabled:

    addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", 
    logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
    
  4. Stop and start the Oracle WebLogic Server.

  5. Perform the following tasks as described in:

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

This topic describes how to configure providers in the WebLogic security domain to perform single sign-on with the Oracle Access Manager Identity Asserter. Several Authentication Provider types must be configured and ordered:

  • OAM Identity Asserter: REQUIRED (also specify a chosen Active Type for the mechanism you are using (Table 15-1))

  • OID Authenticator: SUFFICIENT

  • DefaultAuthenticator: SUFFICIENT

The following procedure uses the WebLogic Administration Console.

Note:

With an Oracle Fusion Middleware application installed, you have the required provider JAR file. Skip Step 1.

To set up Providers for Oracle Access Manager single sign-on in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider:

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

      oamAuthnProvider<version number>.zip  
      
    3. Extract and copy oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      $BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
      
  2. With Oracle Fusion Middleware Application Installed: Perform the following steps if needed:

    1. Locate oamauthenticationprovider.war in the following path:

      $ORACLE_HOME/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  
      
  3. Log in to the WebLogic Administration Console.

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

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

    1. Click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

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

    3. Click the Common tab, set the Control Flag to REQUIRED.

    4. On the Common tab, specify one Chosen Active Type for your SSO mechanism (Table 15-1). For example:


      OAM_IDENTITY_ASSERTION
    5. Save the configuration.

  6. OID Authenticator: An authentication provider must be added to match the LDAP configuration used by Oracle Access Manager, as described in "Configuring Providers in the WebLogic Domain". Perform the following steps and see your Administrator for LDAP details, if needed.

    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

      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)

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

      Save.

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

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

  9. Activate Changes: In the Change Center, click Activate Changes.

  10. Reboot Oracle WebLogic Server.

  11. Proceed as follows:

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.

Note:

The OAM 11g Server displays a login page. No set up is needed.

16.2.4.3 Trusted Header Assertion: Configuring Digital Signature Verification

To use Oracle Access Manager Identity Assertion, the Oracle Access Manager certificate public key is required for digital signature verification. In this task you provision the Identity Asserter keystore for consumption of the OAM certificate with the public key in oamiap-keystore.jks. The certificate, which is consumed by the Identity Asserter, must be in the .oamkeystore.

For the SSO Sync Filter to consume the certificate, you need to provide the truststore to the filter. SSO Sync Filter behavior can be altered for application requirements by passing various over-riding system properties to WebLogic. To do this, you add a property in Oracle WebLogic startup script (setDomainEnv.sh) under EXTRA_JAVA_PROPERTIES. The truststore location can be provided as the system property. By default, the filter looks for keystore at the ssofilter.jar location. If not found there, it looks in system property.

The following procedure guides as you retrieve the .oamkeystore password required to perform export and import operations. After you export and import the required OAM certificate, you provision the keystore to enable the Identity Asserter to consume the certificate. Finally, you choose the OAM_IDENTITY_ASSERTION token type, provision the certificate in the SSO Sync Filter, and confirm that the authorization policy enables Identity Assertion.

To configure digital signature verification for trusted header assertion

  1. Retrieve the .oamkeystore password using script tool as follows:

    1. Locate the WLST tool in your $MW_HOME/Oracle_IDM1/common/bin.

    2. Execute wst.sh: $ ./wlst.sh.

    3. Confirm execution with the following onscreen messages:

      Initializing WebLogic Scripting Tool (WLST) ...
      
      Jython scans all the jar files it can find at first startup. Depending on 
      the system, this process may take a few minutes to complete, and WLST may
      not return a prompt right away
      
      Welcome to WebLogic Server Administration Scripting Shell
      
      Type help() for help on available commands
      
    4. Execute wls:/offline> connect() and supply information for your environment (WebLogic Administrator username and password and AdminServer URL). For example:

      Please enter your username: weblogic  
      Please enter your password: password 
      Please enter your server URL //localhost:7001  
      not return a prompt right away
      
      Connecting to ... 
      Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'.
      
      Warning: An insecure protocol was used to connect to the server. 
      To ensure on-the-wire security, the SSL port or Admin port should be used 
      instead. 
      wls:/base_domain/serverConfig
      
    5. Execute wls:/base_domain/serverConfig> domainRuntime() and check the following onscreen messages. For example:

      Location changed to domainRuntime tree. This is a read-only tree with   
      DomainMBean as the root
      
      For more help, use help(domainRuntime) 
      
      wls:/base_domain/domainRuntime>  
      
  2. Export the alias to a certificate file using the JDK6 keytool, as follows:

    jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore 
    -storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer
    
  3. Import the certificate file using the JDK6 keytool, as follows:

    Note:

    The keystore alias oam.assertion.cert and the keystore name oamiap-keystore.jks are fixed. Use those names only.

    jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file   
    assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password 
    -storetype JKS 
    
  4. Provision the Identity Asserter keystore for consumption of the OAM certificate with the public key in oamiap-keystore.jks:

    1. From the WebLogic Console, Security Realm, Identity Asserter entry, add the absolute path of oamiap-keystore.jks in the provider-specific configuration.

    2. Select token type OAM_IDENTITY_ASSERTION in provider-specific configuration.

    3. Save this configuration.

    OAM Keystore Asserter
  5. Provision .oamkeystore in the SSO Sync Filter, as follows:

    By default, the filter looks for the keystore in the ssofilter.jar location. If not found there, the system property is checked.

    1. Default configuration: Place the keystore file oamiap-keystore.jks in the same location as ssofilter.jar. For example: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1

    2. Fallback Mechanism: Set the keystore file oamiap-keystore.jks as a systemproperty in setDomainEnv.sh ($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh):

      -Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks
      
  6. Set System Properties for OAM_IDENTITY_ASSERTION, as follows:

    1. Stop the WebLogic Server.

    2. Open the file setDomainEnv.sh in $MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh

    3. Add the following property under EXTRA_JAVA_PROPERTIES, and save the file:

    -Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION
    
  7. Start the WebLogic Server.

  8. Proceed to "Trusted Header Assertion: Configuring Policies".

16.2.4.4 Trusted Header Assertion: Configuring Policies

To use OAM_IDENTITY_ASSERTION as a token type for the assertion, the Identity Assertion option must be enabled within the authorization policy that protects the resources. Default policies are generated during agent registration. You can also create policies manually using the Oracle Access Manager Console.

Figure 16-6 provides an example of an authorization policy for the Trusted Header Assertion mechanism.

Figure 16-6 Sample Authorization Policy for Trusted Header Assertion

Surrounding text describes Figure 16-6 .

The following procedure provides the steps to enable Identity Assertion within the Oracle Access Manager 11g authorization policy that protects the resources.

To enable Identity Assertion for Trusted Header Assertion

  1. From the Policy Configuration tab, navigation tree, open the following nodes:


    Application Domains
    Desired Domain
    Authorization Policies
    PolicyName
  2. Enable Identity Assertion (check the box).

  3. Resources:

    • On the Resource tab, confirm the desired resources are protected by this policy.

    • Add or remove resources as needed.

  4. Click Apply to save changes and close the Confirmation window.

  5. Close the page when you finish.

  6. Proceed with "Testing Oracle Access Manager Identity Assertion for Single Sign-on".

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

The following procedure describes how to test your Oracle Access Manager Identity Assertion setup, regardless of the mechanism you are using.

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 with Oracle Security Token Service.

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.

16.2.5 Configuring the Authenticator Function for Oracle Access Manager 11g

With the Authenticator function, 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 and available in the pre-seeded application domain that is delivered with Oracle Access Manager 11g. It protects the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add Responses and Constraints to policies. However, no other configuration is needed.

For more information about the pre-seeded application domain, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

Prerequisites

Tasks to configure the Oracle Access Manager Authenticator are described in the following overview.

Task overview: Configuring the Authenticator function for OAM includes

  1. Ensuring that all prerequisite tasks have been performed

  2. Configuring Providers for the Authenticator in a WebLogic Domain

  3. Configuring the Application Authentication Method for the Authenticator

  4. Mapping the Authenticated User to a Group in LDAP

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

  6. Testing the Oracle Access Manager Authenticator Implementation

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

Note:

When an Oracle Fusion Middleware application is installed, you have the required files and can skip Step 1.

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_HOME/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 Oracle Access Manager 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 Oracle Access Manager Console).

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

      Advanced Configuration: Following are several advanced configuration values.

      Transport Security: The communication mode between OAM 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 Oracle Access Manager 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 Oracle Access Manager Console.

      Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication provider uses to send authentication requests to the OAM 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".

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

Note:

For the Oracle Access Manager Authenticator, Oracle recommends auth-method BASIC in login-config within web.xml.

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

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

16.2.5.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 with Oracle Security Token Service.

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.

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

This section describes how to set up the Oracle Access Manager Identity Asserter to enable validation of the token when you have Oracle Web Services Manager protecting Web services.

As discussed earlier, the Oracle Access Manager Identity Asserter works in two modes. The default mode of operation simply asserts the header that is set by WebGate at the perimeter, which handles most SSO situations. The alternate mode uses the custom AccessGate in oamAuthnProvider.jar. In this case, and with the absence of the header, the Identity Asserter contacts the OAM Server to validate the token. For more information about the token, see "Installing the Authentication Provider with Oracle Access Manager 11g".

Note:

The 10g custom AccessGate provided with the Authentication Provider is required for Identity Assertion for Oracle Web Services Manager.

With OAM 10g, you would need to manually create the policy domain and policies for this configuration. However, with OAM 11g, a pre-seeded application domain is delivered with policies that protect the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add policies, Responses, or Constraints for resources of type wl_authen only. Ideally, however, you can use this application domain with no further configuration. For more information, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

When the Oracle Access Manager Identity Asserter is configured for both header and token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the OAM Server to validate the token. For more information on the token, see "Oracle Access Manager Authentication Provider Parameter List".

Prerequisites

Installing the Authentication Provider with Oracle Access Manager 11g

Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

Task overview: Deploying the Identity Asserter with Oracle Web Services Manager includes

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

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

  3. Testing the Identity Asserter with Oracle Web Services Manager

16.2.6.1 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 primary OAM Server host and port. 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 Oracle Access Manager Console.

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

Note:

With a Oracle Fusion Middleware application installed, you have the required provider file. Skip Step 1.

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 Active Type for the 10g custom AccessGate, and click Save.

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

      Primary Access Server: Specify the primary OAM Server host and port. 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:

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

16.3 Configuring Centralized Log Out for Oracle Access Manager 11g

This section introduces Centralized logout for Oracle Access Manager 11g.

With OAM 11g, centralized logout refers to the process of terminating an active user session. Guidelines include:

Note:

Oracle strongly recommends that applications use the ADF Authentication servlet, which in turn interfaces with OPSS, where a domain wide configuration parameter can be used to specify the logout URL. This way applications need not be modified or redeployed to change logout configuration.

For more information, see:

16.3.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 (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 with Oracle Security Token Service.

16.3.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. In your logout.html, confirm (from Step 1), confirm that the user is redirected to the central logout URI on the OAM 11g Server, "/oam/server/logout'.

  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 with Oracle Security Token Service.

16.4 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the container's user session with the user identifying header in OSSO (Proxy-Remote-User) or the user data in the Oracle Access Manager SSO session cookie (ObSSOCookie).

SSO Synchronization Filter (SSO Sync Filter) is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with container's user session.

SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie (JSESSIONID).

Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter:

The job of SSO Sync Filter is to ensure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the container's user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use.

Notes:

You can alter the behavior of the SSO Sync Filter for application requirements by passing various over-riding system properties to WebLogic. To do this, you change the Oracle WebLogic startup script and check for EXTRA_JAVA_PROPERTIES in setDomainEnv.sh. The properties and Sync behavior is shown in Table 16-6.

Table 16-6 SSO Sync Filter Properties and Sync Behavior

Area Overriding System Property Default value of System property Default Behavior of the Sync Filter

Status (Active or Inactive)

sso.filter.enable

Not configured

Enabled

Case sensitive matches

sso.filter.name.exact.match

Not configured

Case Ignore Match

Configured Tokens

sso.filter.ssotoken

Not configured

  • OSSO: Look for Proxy-Remote-User

  • Oracle Access Manager: Look for OAM_REMOTE_USER and REMOTE_USER.

    OAM_REMOTE_USER takes precedence.

URI Mappings

Not Applicable

Not Applicable

/*


You cannot enable the filter for selected applications. The SSO Sync Filter is a system filter. As such, it is activated for all deployed applications (the URI mapping is /*).

Note:

You cannot enable the filter for selected applications.

The following procedure gives some tips about modifying the SSO Sync filter properties and behavior.

To modify the SSO Sync Filter properties and behavior

  1. Disable the Filter: Change the system property "sso.filter.enable" to "false" (pass as -D to the jvm) and restart the Oracle WebLogic Server. This toggles the filter status.

  2. User-Identifying Header Differs from Pre-Configured Sync Filter Tokens: Over-ride the SSO token that the Sync Filter looks for using the system property "sso.filter.ssotoken".

    For example, pass to the WebLogic Server jvm in the WebLogic Server startup script -Dsso.filter.ssotoken=HEADERNAME, and restart the server.

When you contact Oracle Support you might be requested to set up debugging, as described in "Setting Up Debugging in the WebLogic Administration Console".

16.5 Troubleshooting Tips

For more information, see "Troubleshooting" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.