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

17 Configuring Single Sign-On Using Oracle Access Manager 10g

The chapter describes how to configure single sign-on using Oracle Access Manager 10g. It includes the following major sections:

17.1 Deploying SSO Solutions with Oracle Access Manager 10g

This section provides the following topics:

17.1.1 Installing and Setting Up Authentication Providers for OAM 10g

This topic provides an overview of Oracle Access Manager installation and initial setup and additional information about installing components and files for use when you deploy the Oracle Access Manager Authentication Provider.

Unless explicitly stated, these topics describe requirements for both the Oracle Access Manager Identity Asserter and the Oracle Access Manager Authenticator:

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

See Also:

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.

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

See Also:

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

Note:

If you already have components installed and set up, you do not need to install new ones. Skip any steps that do not apply to your deployment.

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

  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.

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

      $ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
      $ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.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
      
  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:

    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.

      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

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

17.1.1.3 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 Oracle Access Manager Access Server in Simple or Cert (certificate) mode.

When communicating in Simple or Cert mode, the Access 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 Access 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 Access 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 inAccessServer_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 Access Server installation directory path. For example:

    AccessServer_install_dir\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 17-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 Oracle Access Manager Access 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 
    
  15. Proceed as follows:

17.1.1.4 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. This task is required if you use the Oracle Access Manager Authenticator or if you have Oracle Web Services Manager policies protecting Web services.

You use the Oracle Access Manager Access System Console to define resource types as described here.

Note:

If you are using the Oracle Access Manager Identity Asserter for single sign-on, you can skip this task. In this case, only the default http resource type is used.

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:

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

This section discusses configuring logout for applications protected by a 10g WebGate with Oracle Access Manager 10g. In Oracle Access Manager 10g, global logout (also known as single log out (SLO) can be handled in various ways. This section describes the recommended method.

Note:

Oracle Access Manager SSO user session tracking is performed using DOMAIN cookies, specifically the ObSSOCookie. WebGates look for the ObSSOCookie. Global or SLO for Oracle Access Manager simply means killing the ObSSOCookie. Without the ObSSOCookie, WebGates enforce a re-authentication workflow.

For more information on killing the ObSSOCookie, see:

17.1.2.1 Recommended Process for Configuring Logout

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

17.1.2.1.1 Configuring WebGate for Logout using the Sample Logout File

WebGate configuration consist of:

  • logout.html: A logout page must be available on the Web server in the WebGate installation directory: WebGate_install_dir/oamsso/logout.html.

    If the file is located elsewhere on the Web server, ensure that the logout link is correctly specified to load logout.html. See the logout.html in Example 17-1, which you can customize further depending on your needs.

  • logOutUrls (optional): If this parameter has already been configured for the WebGate, the value "/oamsso/logout.html" must be added to the existing list.

  • Web Server Configuration: Check the Oracle HTTP Server Web server configuration file, httpd.conf, on which the 10g WebGate is configured and delete the following lines if they are present

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

Use Example 17-1 when you begin constructing a logout.html for logout configuration for an application protected by 10g WebGate in an OAM 10g deployment.

Example 17-1 logout.html Script

<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>
17.1.2.1.2 Configuring Applications for Logout

Application configuration for logout depends on whether it is an ADF application integrated with OPSS or if it is not integrated with OPSS.

Note:

The logout configuration assumes that the applications are present in a single DNS domain. If you would like SLO (single log out) across applications deployed on different DNS domains, you must customize the logout script to ensure processing for each WebGate. If you have a multi DNS domain deployment, see the Oracle Access Manager Access Administration Guide.

One of the following must be done to configure the application for logout:

  • A non-ADF application must be coded to invoke the logout link: "/oamsso/logout.html?end_url=<target uri>".

  • An ADF application that has been integrated with OPSS requires configuring OPSS for the OAM SSO provider and the application must send the 'end_url' parameter.

Non-ADF Application

A non-ADF application must be coded to invoke the link for logout: "/oamsso/logout.html?end_url=<target uri>".

The application can pass a parameter (named end_url) indicating the location where the user should eventually be redirected to after logout. The value that is part of end_url could either be a URL or a URI. For example, the logout link for the application might be specified as

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

or

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

If the end_url querystring is a URI, then the logout.html must construct the URL by determining the host:port of the server where logout.html is hosted.

ADF-Coded Applications

If the Application is an ADF application that has been integrated with OPSS, then you can use the following procedure to configure logout.

To configure centralized logout for ADF-coded applications

  1. Check with the OAM Administrator to confirm the location of the logout.html script configured with the Agent, which you need in following steps.

  2. Configure OPSS for OAM as the SSO provider to update jps-config.xml for the WebLogic administration domain, as follows:

    1. Run wlst.sh (Linux) or wlst.cmd (Windows) from the following directory path:

      WLST_install_dir/middleware/oracle_common/common/bin 
      
    2. At the WLS prompt, enter the OAM administrator ID and password and the WebGate host and port:

      >java weblogic.WLST
      >connect('userName', 'userPassword', 'url', 'adminServerName')
      

      The last parameter is optional if the server is running on localhost at the default port (7001).

    3. Enter the login URI for ADF authentication and the logout URI (location of the logout.html script configured with the agent); the host and port are not needed.

      wls:/>addOAMSSOProvider(loginuri="/$<loginuri>",    
      logouturi="<logouturival>," autologinuri=None")
      

      Here, logouturival is the URI of the logout script /oamsso/logout.html. The logouturl could either begin with "logout" (exceptions are logout.gif and logout.jpg) or could be any other value configured by the OAM Administrator.

  3. Required: The ADF application must pass the end_url parameter indicating where to redirect the user after logout. For ADF applications, logout is initiated when the application causes the following URI to be invoked:

    /<app context root>/adfAuthentication?logout=true&end_url=<any uri>
    

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

Note:

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

17.2 Oracle Access Manager Authentication Provider Parameter List

This section enumerates the common and provider-specific parameters relevant to the Oracle Access Manager Authentication Provider. These are specified in the Oracle WebLogic Administration Console. For more information, see:

Table 17-2 Oracle Access Manager Authentication Provider Common Parameters

Parameter Name Parameter Description

Name

The name of the provider. Read-only.

Description

The description of the provider. Read-only.

Version

The version of the provider. Read-only.

Control Flag

The provider JAAS control flag. Set one of the following: REQUIRED, REQUISITE, OPTIONAL, or SUFFICIENT. When configuring multiple Authentication Providers, use this flag to control how they are use in the login sequence. See JAAS Control Flag.

Active Types

This parameter is relevant to only Oracle Access Manager Identity Asserter. This parameter determines the token types that the Identity Asserter Provider processes. Set as follows for OAM 10g and 10g WebGate:

  • OAM 10g and 10g WebGate: ObSSOCookie

  • OAM_REMOTE_USER

Base64 Decoding Required

False is Read-only (the default).


The WebLogic Server Administration Console sets the JAAS Control Flag to OPTIONAL when you create a new security provider. The default value for out-of-the-box security providers is REQUIRED. For more details about the control flag, see the online help.

Table 17-3 lists the provider-specific parameters for Oracle Access Manager the Authenticator or the Identity Asserter for Oracle Web Services Manager.

Note:

With OAM 11g, the Access Server is known as the OAM Server.

Table 17-3 Provider-Specific Parameters

Parameter Name Parameter Description

Transport Security

The mode of communication between AccessGate and Access Server.

Minimum Access Server Connections In Pool

The minimum number of connections allowed. Default is 5.

Access Gate Password

The password of the AccessGate used by the provider.

Key Store Pass Phrase

The password to access the key store.

Access Gate Name

The name of the AccessGate used by the provider. Required.

Primary Access Server

The name of the primary access server. It must conform to the format host:port. Required. See "Installing and Setting Up Authentication Providers for OAM 10g".

Maximum Access Server Connections In Pool

The maximum number of connections allowed. Default is 10. Set to 1.

Simple Mode PassPhrase

The password shared by AccessGate and Access Server for Simple or Cert communication modes.

Trust Store

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

SSOHeader Name

OAM_REMOTE_USER

Secondary Access Server

The name of the secondary access server. It must conform to the format host:port. See "Installing and Setting Up Authentication Providers for OAM 10g".

Key Store

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


Table 17-4 lists provider-specific parameters for the Oracle Access Manager Authenticator.

Table 17-4 Provider-Specific Parameters: Oracle Access Manager Authenticator

Parameter Name Parameter Description

Transport Security

The mode of communication between AccessGate and Access Server.

Maximum Access Server Connections In Pool

The maximum number of connections allowed. Default is 10. Set to 1.

Simple Mode Pass Phrase

The password shared by AccessGate and Access Server for simple or cert communication modes.

Minimum Access Server Connections In Pool

The minimum number of connections allowed. Default is 5.

Trust Store

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

Use Retrieved username As Principal

Specifies whether to use the user name retrieved from Oracle Access Manager as the Principal in the Subject.

Access Gate Password

The password of the AccessGate used by the provider.

Key Store Pass Phrase

The password to access the key store.

Access Gate Name

The name of the AccessGate used by the provider. Required.

Secondary Access Server

The name of the secondary access server. It must conform to the format host:port. See:

Key Store

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

Primary Access Server

The name of the primary access server. It must conform to the format host:port. Required. See:


17.3 Introduction to OAMCfgTool

This topic introduces OAMCfgTool, which can be used only if you are deploying the Oracle Access Manager 10g Identity Asserter for single sign-on.

OAMCfgTool launches a series of scripts to request information and set up the required profiles and policies in Oracle Access Manager 10g. OAMCfgTool runs in the following modes:

Unless you specify an LDIF output file, configuration changes are written directly in the LDAP directory server that is configured with Oracle Access Manager. In addition, without an LDIF file, OAM Access Server's cache is updated with the configuration changes.

Note:

When configuration changes are written to an LDIF file, it can be loaded into the directory server for Oracle Access Manager at a later time.

You can also specify a log level and an output file for logging details. If errors occur when running OAMCfgTool, these are reported on the command line.

Passwords

OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode, and Test user.

Without the -noprompt parameter, OAMCfgTool attempts to fetch passwords first from the command line. If no password is found, then OAMCfgTool pauses and prompts for a password to be entered on the command line.

However if you specify the -noprompt parameter, OAMCfgTool checks for passwords passed from the command line:

Passwords can be passed from a shell using an echo command and a semi-colon as a separator. For instance:

For more information, see "OAMCfgTool Parameters and Values".

17.3.1 OAMCfgTool Process Overview

This topic describes the processing that occurs when you use OAMCfgTool with various parameters and values for your environment.

This topic focuses on using OAMCfgTool for OAM 10g. If you are using OAM 11g, skip this topic and instead refer to the chapter Chapter 16, "Configuring Single Sign-On with Oracle Access Manager 11g".

Process overview: OAMCfgTool creates the authentication scheme, policy domain, and WebGate profile

  1. The app_domain parameter creates a policy domain in the Policy Manager to enable authentication for the application.

  2. The web_domain parameter creates a host identifier that connects the WebGate host sending requests to your application and links the policy to the existing WebGate.

    Note:

    See the web_domain parameter in Table 17-5.

  3. The protected_uris parameter defines application-specific URL's to protect HTTP resources using the host identifier.

  4. The public_uris parameter creates a policy to protect certain URIs with the Anonymous Authentication scheme for http resources (GET and POST operations) in the app_domain name.

    Note:

    See the uris_file parameter in Table 17-5 for details about specifying protected and public URIs in a file.

  5. The LDAP parameters specify the directory server used by Oracle Access Manager to identity the searchbase from which all LDAP queries are performed. For more information, see Table 17-5

  6. The log file and level parameters specify an output file and logging level for OAMCfgTool.

  7. The output_ldif_file parameter defines the name of the LDIF file that is created to be loaded later in the directory server, if specified. Otherwise, configuration changes are written to the directory server

17.3.2 OAMCfgTool Parameters and Values

Find the following topics here:

17.3.2.1 Create Mode Parameters and Values

Table 17-5 provides both required and optional OAMCfgTool parameters and values for CREATE mode. You can specify multiple parameters at one time.

Table 17-5 OAMCfgTool CREATE Mode Parameters and Values

Parameters CREATE Mode Values

Required Parameters

Required Parameter Values

app_domain

Name of the Oracle Access Manager policy domain to protect the application. Within the Policy Manager this is known as the policy domain name.

protected_uris

URIs for the protected application in a comma separated list (with or without spaces): /myapp/login, for example.

See Also: The uris_file parameter in this table.

uris_file

The full path to a file containing any number of protected or public URIs and eliminates the need to use the protected_uris or public_uris parameters. Ensure that the file uses the following syntax and format:


--At least one protected URI is required.
--Only one product family is allowed per file.
--Comments begin with '#'
--Keyword: public_uris. List public URIs on separate lines after this key word.
--Key word: protected_uris. List URIs to be protected on separate lines after this key word.
For example:
######################## 
#Finance
######################## 
.
######################## 
protected_uris 
######################## 
/finance/protected/test1 
/finance/protected/test2
######################## 
public_uris 
######################## 
/finance/public 
/finance/protected/test1/public 

app_agent_password

Password to be provisioned for the WebGate. In the AccessGate Profile within the 10g Access System Console, this parameter is known as the AccessGate Password. Your entry appears in clear text on the command line but is not captured in a log file.

Note: This parameter is not required if you will not create a WebGate profile. See Also: -noprompt later in this table and the discussion "Passwords".

ldap_host

DNS name of the computer hosting the LDAP directory server for Oracle Access Manager. This is the directory server containing the OAM policy data.

Note: SSL-enabled communication with the directory server is not supported.

ldap_port

Port of the LDAP directory server.

ldap_userdn

The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN.

ldap_userpassword

Password of LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: -noprompt later in this table.

See Also: -noprompt later in this table and the discussion "Passwords".

oam_aaa_host

DNS name of the computer hosting an accessible Access Server.

After making appropriate changes to the Directory Server, a Cache flush request would be sent to this Access Server so that Access Servers refresh their appropriate caches.

If the 'primary_oam_servers' parameter is not specified, then the WebGate profile being created would be configured to use the Access Server, specified as part of oam_aaa_host, as the Primary Access Server. Number of connections would default to 1.

See Also: primary_oam_servers and secondary_oam_servers, later in this table.

oam_aaa_port

Listening port on the accessible Access Server

Optional Parameters

Optional Parameter Values

help

Provides a list of parameters and descriptions.

version

Lists the version of the OAMCfgTool.

web_domain

Primarily used to specify the host identifier.

Note: OAMCfgTool either creates a host identifier and Webgate profile together or does not create either of them, as described in the following two scenarios:

Creation of a Fresh Web Tier: If the host identifier specified by the parameter "web_domain" (or "app_domain" if "web_domain" is not specified) does not exist in OAM, then the following would be created in OAM:

  1. A new host identifier is created with the value specified by "web_domain" (or "app_domain" if "web_domain" is not specified).

  2. A new WebGate profile, the name of which is derived using the following rules:

    a. If "webgate_id" is specified, then the WebGate profile is created with the value specified in "webtate_id"

    b. If "webgate_id" is not specified, then the WebGate profile is created with the value specified in "web_domain" with "_AG" appended to it. For example: <web_domain>_AG.

    c.If "webgate_id" and "web_domain" are not specified, then the WebGate profile is created with the value specified in "app_domain" with "_AG" appended to it. For example: <app_domain>_AG.

  3. The value of the "Preferred Http Host" field of the WebGate profile and the "hostname variations" as part of the Host Identifier created in step 1 above are automatically populated with a same value.

See Also: The hostname_variations parameter in this table for configuring virtual hosts.

Using an existing Web Tier (Join a web domain): If the host identifier specified as part of "web_domain" (or "app_domain", if "web_domain" is not specified) exists in OAM, then:

  • A host identifier is not created

  • A WebGate profile is not created

Note: The host identifier created in a fresh Web Tier is used in the policy domain being used.

If virtual Web hosting is supported, supply a reserved name in the Preferred HTTP Host field instead of a host name variation.

See Also: The hostname_variations parameter in this table and the Oracle Access Manager Access Administration Guide.

cookie_domain

Name of the domain to use for the ObSSOCookie. Within the AccessGate Profile in the Access System Console, this is known as the Primary HTTP Cookie Domain.

Use this parameter when you create a new WebGate profile in a fresh Web Tier.

public_uris

URIs that must be unprotected using the Anonymous authentication scheme. You can identify public URIs by providing a comma separated list: "uri1,uri2,uri3", for example.

See Also: The uris_file parameter in this table.

ldap_base

Base from which all LDAP searches are performed.

oam_aaa_mode

Transport security mode of the accessible Access Server: OPEN, SIMPLE, or CERT. Default presumes OPEN.

oam_aaa_passphrase

Passphrase required for SIMPLE mode transport security mode only. The passphrase appears in clear text but is not captured in a log file.

See Also: The discussion "Passwords".

log_file

Name of the OAMCfgTool log file. Output to the screen is the default.

log_level

Level for OAMCfgTool logging: ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, OFF.

Default = WARNING

output_ldif_file

Name of the LDIF file in which to store details from OAMCfgTool operations to load into the LDAP directory server later. If none is specified, changes are written immediately to the LDAP directory server and caches in Oracle Access Manager are flushed to make new information available.

noprompt

Disables password prompts from OAMCfgTool and enables password checks as follows:

  • If no password was passed from the command line, then OAMCfgTool checks for passwords passed from System.in. See Also: "Passwords" for more information.

  • If no password is passed from System.in, OAMCfgTool stops execution with an exception indicating that the required password was not provided.

authenticating_wg_url

URI containing the host and port of the authenticating WebGate (when you have both an authenticating and a resource WebGate). For example:

authenticating_wg_uri=http://host:port

This parameter configures the "Challenge Redirect Parameter" of both the following authentication schemes:

  • OraDefaultFormAuthenNScheme

  • OraDefaultI18NformAuthenNScheme

Note: The 'Challenge Redirect' parameter is added when the authentication scheme is created. The 'Challenge Redirect' parameter of an existing authentication scheme is not updated.

configOIMPwdPolicy

Creates the Oracle Identity Manager (OIM) password policy to automate integration with Oracle Access Manager. Also, the corresponding authentication scheme used by the policy is enabled to check password policies.

See Also: "OIM Integration-Related Parameters and Values".

OimOhsHostPort

Required when integrating Oracle Identity Manager (OIM) with Oracle Access Manager and an authentication WebGate and resource WebGate.

See Also: "OIM Integration-Related Parameters and Values".

Not required without an authenticating WebGate. In this case, Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) automates integration with Oracle Access Manager and the corresponding authentication scheme used by the policy is enabled to check password policies. Default values are used for the password policy-related parameters with the value in OimOhsHostPort prepended to these. For example:

-OimLostPwdRedirectUrl  (Lost Password Redirect URL): 
<OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx 
-OimPwdRedirectUrl (Password Change Redirect URL): 
<OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% 
-OimLockoutRedirectUrl (Account Lockout Redirect URL): 
<OimOHSHostPort>/ApplicationLockoutURI 

OimOhsHostPort parameter is applicable only if the -configOimPwdPolicy flag is present.

See Also: "OIM Integration-Related Parameters and Values".

logouturi

Facilitates configuration of LogoutRedirectUrl on the Resource WebGate by pointing to the URL location on the Authenticating WebGate where the perl script for logout is configured.

The value of logouturi parameter must be a URI. The WebGate LogoutRedirectUrl parameter is configured using the authenticating_wg_url and logouturi parameters:

http://<awghost>:<awgport>/cgi-bin/logout.pl

LogoutRedirectUrl http://myhost.us.myco.com:7777/cgi-bin/logout.pl.

Note: Do not configure the LogoutRedirectUrl parameter on the authenticating WebGate itself. Instead, leave the LogoutRedirectUrl blank on the authenticating WebGate.

To configure the logout URI when you create an application domain and provision a fresh WebGate:

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) 
java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl
-noprompt

Note: To use an existing WebGate, use the webgate_id parameter as described next.

webgate_id

Specifies the name of the existing WebGate for which "LogoutRedirectUrl" is not yet configured.

Notes: The WebGate profile is created only if the corresponding host identifier does not already exist in Oracle Access Manager. Further:

  • If you do not provide webgate_id, the profile is created with the name specified with the value of web_domain, appended with _AG (web_domain_AG).

  • If web_domain is not specified, then app_domain is used to create the name of the profile, appended with _AG (app_domain_AG)

Following is a sample command using webgate_id.:

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) 
java -jar oamcfgtool.jar app_domain=myapp webgate_id=MyWebgate 
protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl
-noprompt

hostname_variations

Enables you to add values to the Hostname Variations section of the Host Identifier in Oracle Access Manager.

To configure virtual hosts for Apache-based Web servers (including OHS), include this parameter as follows:

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=vhost1,vhost2 

Note:

  • If a host identifier specified with web_domain parameter does not exist in Oracle Access Manager, it is created and values of hostname_variations are added to the hostname variations section of this host identifier.

  • If the specified host identifier already exists in Oracle Access Manager, values of hostname_variations are appended to the existing set of hostname variations for the host identifier.

  • If the WebGate profile identified by the webgate_id parameter (or the web-domain parameter or the app_domain parameter) does not exist, it is created and its "preferred http host" field is set to 'SERVER_NAME: the preferred_http_host parameter is not required in this case.

To configure virtual hosts for non-Apache-based Web servers, include the parameter, preferred_http_host as described next.

preferred_http_host

Makes configurable the Preferred Http Host field of the WebGate profile.

To configure virtual hosts for non-Apache-based Web servers, include this parameter, with a value of HOST_HTTP_HEADER, as follows:

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=vhost1,vhost2 preferred_http_host=HOST_HTTP_HEADER

You can simply add multiple hostname variations to a host identifier using the hostname_variations and preferred_http_host parameters as follows:

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=hostname1,hostname2 preferred_http_host=SOME_
HOSTNAME_VARIATION_VALUE

The virtual environment notes apply. Additionally, if the WebGate profile is being created, then you can set the preferred http host field of the profile to any value from the hostname variations

Generally, you do not need additional hostname variations when creating a host identifier in a non-virtual host environment. OAMCfgTool adds a default value to the preferred http host field of the WebGate profile and to the hostname variation section of the host identifier being created.

default_authn_scheme

Configures the default authentication scheme for a policy domain. You must pass the authentication scheme name as displayed in the Access System Console.

OAMCfgTool always provisions the following authentication schemes:

  • OraDefaultBasicAuthNScheme: The default Basic authentication scheme

  • OraDefaultFormAuthNScheme: The default Form authentication scheme

  • OraDefaultI18NFormAuthNScheme: The default i18n authentication scheme

  • OraDefaultAnonAuthNScheme: The default Anonymous Authentication scheme

The first time you run the tool in a new deployment, the schemes in the previous list are created.

The authentication scheme specified as part of the "default_authn_scheme" parameter is used to configure the Default Authentication Rule section of the Policy Domain being configured.

With the OAM URIs file, you can configure the authentication scheme for a protected policy (policies that are specified after the key word "protected_uris" for the Policy Domain. You must pass the Authentication Scheme name in the URIs file in the following format (the policy name and authentication scheme name must be separated by a tab character):

<Policy Name> 'tab' <Authentication Scheme Name>.

Following is an example of entries in a URIs file (for more information, see the uris_file parameter earlier in this table):

#-----------------------------------------------------
protected_uris

protected policy1   Basic Over LDAP 
/protected1 public1/mystuff.html

protected policy2   OraDefaultFormAuthNScheme 
/protected2/public2/prot2    /.../{*.js,*.png,*.gif} 

protected policy3   Client Certificate 
/protected2/public2/prot2/.../{*.js,*.png,*.gif} 
#------------------------------------------------------

The previous entries in a URIs file produce the following named policies:

  • protected policy1 is configured to use the Basic Over LDAP scheme

  • protected policy2 is configured to use the OraDefaultFormAuthNScheme scheme

  • protected policy3 is configured to use the Client Certificate scheme

max_oam_connections

Supports high availability and multiple Access Servers by specifying the maximum number of connections ('Maximum Connections') for the WebGate profile being created.

primary_oam_servers

Supports high availability and multiple Access Servers by configuring the WebGate profile with more than one primary Access Server. The format of this parameter is:

  • Colons join each Access Server name with the number of connections to the WebGate. For example: primary_oam_servers="aaaid1:3". If no numeric value is specified, the default is 1.

  • Comma-separated list of Access Server names and the number of connections to the WebGate. For example: primary_oam_servers="aaaid1:3,aaaid2:1,aaaid3,aaaid4:2"

Notes:

  • Access Server IDs must exist within OAM and must be unique (no duplicates and not present in both primary and secondary values).

  • Transport Security mode of WebGate and Access Servers must match.

  • The Access Management Service mode of WebGate and Access Server must match.

secondary_oam_servers

Supports high availability and multiple Access Servers by configuring the WebGate profile with more than one secondary Access Server. The format of this parameter is:

  • Colons join each Access Server name with the number of connections to the WebGate. For example: secondary_oam_servers="aaaid1:3". If no numeric value is specified, the default is 1.

  • Comma-separated list of Access Server names and the number of connections to the WebGate. For example: secondary_oam_servers="aaaid1:3,aaaid2:1,aaaid3,aaaid4:2"

Notes:

  • Access Server IDs must exist within OAM and must be unique (no duplicates and not present in both primary and secondary values).

  • Transport Security mode of WebGate and Access Servers must match.

  • The Access Management Service mode of WebGate and Access Server must match.


17.3.2.1.1 OIM Integration-Related Parameters and Values

Table 17-6 identifies OIM integration-related parameters and values for OAMCfgTool.

See Also:

The section on integrating Oracle Access Manager 10g with Oracle Identity Manager 11g in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management

Table 17-6 Additional OIM Integration-Related Parameters and Values

Parameter Description

configOIMPwdPolicy

Creates the Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) to automate integration with Oracle Access Manager. Additionally, the corresponding authentication scheme used by the policy is enabled to check password policies.

For example, if the policy is used with the default authentication scheme (OraDefaultFormAuthnScheme), then the scheme's "Validate_Password" plug-in is updated to include 'obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"'.

Note: Use default values for password-related parameters in Identity System Console, prepended with the value specified with OimOhsHostPort.

When configOIMPwdPolicy is used, ensure that you do not have the default OIM password policy created using the tool previously and do not pass any of the following parameters:

When configOIMPwdPolicy is used, ensure that you do not have the default OIM password policy created using the tool previously and do not pass any of the following parameters:

OimOhsHostPort

Required when integrating Oracle Identity Manager (OIM) with Oracle Access Manager and an authentication WebGate and resource WebGate.

Not required without an authenticating WebGate. In this case, Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) automates integration with Oracle Access Manager and the corresponding authentication scheme used by the policy is enabled to check password policies. Default values are used for the password policy-related parameters with the value in OimOhsHostPort prepended to these. For example:

-OimLostPwdRedirectUrl  (Lost Password Redirect URL): 
<OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx 
-OimPwdRedirectUrl (Password Change Redirect URL): 
<OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% 
-OimLockoutRedirectUrl (Account Lockout Redirect URL): 
<OimOHSHostPort>/ApplicationLockoutURI 

OimOhsHostPort parameter is applicable only if the -configOimPwdPolicy flag is present.

OimPwdRedirectUrl

Required for configOIMPwdPolicy. Configures the Password Change Redirect URL parameter in Oracle Access Manager.

OimLockoutRedirectUrl

Required for configOIMPwdPolicy. Configures the Custom Account Lockout Redirect URL parameter in Oracle Access Manager.

OimLostPwdRedirectUrl

Required for configOIMPwdPolicy. Configures the Lost Password Redirect URL parameter in Oracle Access Manager.


Note:

This is a one time setup requirement. If the OraOIMDefPasswdPolicy policy already exists, it is not created anew. You must restart the Identity and Access Servers after this operation. See Example 17-2.

Example 17-2 OIM Integration-Related Parameter Usage

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) 
java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -configOIMPwdPolicy
OimPwdRedirectUrl="http://oimredirectutl.com
OimLockoutRedirectUrl="http://oimlockouturl.com"
OimLostPwdRedirectUrl="http://oimLostpwdurl.com"
-noprompt

17.3.2.2 Validate Mode Parameters and Values

Master or Delegated Access Administrators can check Oracle Access Manager directly to validate policy domain and WebGate profile setup.

Note:

You cannot use OAMCfgTool mode to validate AccessGate profile creation.

Using OAMCfgTool in VALIDATE mode, you can ensure that the policy domain for single sign-on configuration is correct. In this case, a set of requests are sent automatically to protected resources.

Table 17-7 provides both required and optional OAMCfgTool parameters and values for VALIDATE mode.

Table 17-7 OAMCfgTool VALIDATE Mode Parameters and Values

VALIDATE Mode Parameters VALIDATE Mode Values for Required Parameters

Required Parameters

Values

app_domain

Name of the Oracle Access Manager policy domain that was created to protect the Application.

ldap_host

DNS name of the computer hosting the LDAP directory server for Oracle Access Manager.

ldap_port

Port of the LDAP directory server.

ldap_userdn

The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN.

ldap_userpassword

Password of the LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: noprompt in this table.

ldap_base

Base from which all LDAP searches are done. In Oracle Access Manager this is known as the search base or configuration base. For example: dc=company,c=us.

oam_aaa_host

DNS name of the computer hosting the Access Server.

oam_aaa_port

Listening port on the Access Server host.

test_username

User name to be used for policy validation.

test_userpassword

User password to be used for policy validation. Passwords appear in clear text but are not captured in a log file. See Also: noprompt in this table.

noprompt

Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. ConfigTool expects four passwords: Ldap user, App agent, OAM mode and Test user:

See Also: noprompt in Table 17-5.

Optional Parameters

Values

web_domain

Host identifier

ldap_base

Base from which all LDAP searches are done. In Oracle Access Manager this is known as the search base or configuration base. For example: dc=company,c=us.

oam_aaa_mode

Transport security mode of the accessible Access Server: OPEN, SIMPLE, or CERT. Default presumes OPEN.

oam_aaa_passphrase

Passphrase required for SIMPLE mode transport security mode only. Your entry appears in clear text. However, it is not captured in a log file.

log_file

Name of the OAMCfgTool log file. Output to the screen is the default.

log_level

Level for OAMCfgTool logging: ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, OFF (the default).

noprompt

Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode and Test user.

See Also Table 17-5.


17.3.2.3 Delete Mode Parameters and Values

Using OAMCfgTool in DELETE mode, you can remove the provisioned policies, the web domain, WebGate registration, and authentication scheme.

Table 17-8 provides both required and optional OAMCfgTool parameters and values for DELETE mode.

Table 17-8 OAMCfgTool DELETE Mode Parameters

DELETE Mode Parameters DELETE Mode Values for Required Parameters

ldap_host

DNS name of the computer hosting the LDAP directory server for Oracle Access Manager.

ldap_port

Port of the LDAP directory server.

ldap_userdn

The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN.

ldap_userpassword

Password of the LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: -noprompt in Table 17-5.

oam_aaa_host

DNS name of the computer hosting the Access Server.

oam_aaa_port

Listening port on the Access Server host.

Optional Parameters

Values

app_domain

To delete the entire application domain, specify only app_domain with no URI-related parameters.

web_domain

web_domain=existing_host_Identifier

To delete the host identifier identified by this parameter and the WebGate registration.

See Also: Table 17-5.

protected_uris

URIs for the protected application in a comma separated list (with or without spaces): /myapp/login, for example.

Deletes one or more protected URIs from an application domain.

See Also: The uris_file parameter in this table.

public_uris

Deletes one or more public URIs from an application domain.

See Also: The uris_file parameter in this table.

uris_file

The full path to a file containing any number of protected or public URIs and eliminates the need to use the protected_uris or public_uris parameters. Ensure that the file uses the following syntax and format.

See Also: Table 17-5.

authn_scheme

The name of the authentication scheme to delete: OraDefAuthSchemes, OraDefaultAWGFormAuthNScheme, OraDefaultI18NFormAuthNScheme.

To delete all three, specify OraDefAuthSchemes:

You can include the following options:

-noconfirm With this parameter there is no prompt for confirmation before deleting.

noprompt

Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode and Test user.

See Also Table 17-5.


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


Name: app_domain value specified with OAMCfgTool.

Policy Domain, General Tab

Figure 17-1 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 17-1 Sample OAMCfgTool Policy Domain General Tab

Sample OAMCfgTool Policy Domain General tab
Description of "Figure 17-1 Sample OAMCfgTool Policy Domain General Tab"

Policy Domain, Resources Tab

Figure 17-2 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 17-2 Sample OAMCfgTool Policy Domain Resources Tab

OAMCfgTool Policy Domain Resources Tab
Description of "Figure 17-2 Sample OAMCfgTool Policy Domain Resources Tab"

Policy Domain, Authorization Rules Tab

Figure 17-3 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 17-3 Sample OAMCfgTool Policy Domain Authorization Rules Tab

OAMCfgTool Sample Authorization Rules Tab
Description of "Figure 17-3 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 17-4 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 17-4.
Actions: There are no actions defined.

Figure 17-4 Sample OAMCfgTool Policy Domain Default Rules Tab

OAMCfgTool Policy Domain Default Rules Tab
Description of "Figure 17-4 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 17-5 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 17-5 Sample OAMCfgTool Policy Domain Policies Tab

OAMCfgTool Policy Domain Policies Tab
Description of "Figure 17-5 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 17-6 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 17-6 OAMCfgTool Policy Domain Delegated Access Admins Tab

OAMCfgTool Delegated Access Admins Tab
Description of "Figure 17-6 OAMCfgTool Policy Domain Delegated Access Admins Tab"

See Also:

"Protecting Resources with Policy Domains" in the Oracle Access Manager Access Administration Guide.

Host Identifiers

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

Figure 17-7 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 17-7 Sample OAMCfgTool Host Identifiers

Sample OAMCfgTool Host Identifiers
Description of "Figure 17-7 Sample OAMCfgTool Host Identifiers"

AccessGate Profile

Figure 17-8 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 17-8 Sample OAMCfgTool AccessGate Profile

Sample OAMCfgTool AccessGate Profile
Description of "Figure 17-8 Sample OAMCfgTool AccessGate Profile"

17.3.4 Known Issues: JAR Files and OAMCfgTool

Table 17-9 identifies known issues with this release. For more information about the tool, parameters, and values, see "Introduction to OAMCfgTool".

Table 17-9 OAMCfgTool Known Issues

Bug Number Description

n/a

The location where you obtain Oracle Access Manager Authentication Provider and OAMCfgTool JAR files when you do not have an Oracle Fusion Middleware application installed could change. If the location is different than the one stated in this chapter, see the Release Notes for the latest information.

8362080

OAMCfgTool provides Create, Validate, and Delete modes. It does not provide an Overwrite option.

8362039

OAMCfgTool does not provide explicit options to specify the Web Tier host and port. Instead, without web_domain specified the app_domain value specifies the WebGate name, host, and Preferred HTTP Host. For example:

  • app_domain=ABC (without web_domain specified)

  • AccessGate Name: ABC_AG

  • Hostname: ABC

  • Port: Not specified

  • Preferred HTTP Host: ABC

n/a

With OAMCfgTool, if web_domain parameter is included in the command line, you must provide a WebGate password. Otherwise, the command can fail.

The app_agent_password parameter accepts as the password whatever follows the equal sign, =. For instance, if you enter app_agent_password= and then enter a space character and web_domain=value, the app_agent_password is presumed to be a space character followed by web_domain.

n/a

SSL-enabled communication with the directory server is not supported by OAMCfgTool.


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

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

Prerequisites

Unless explicitly noted for the Authenticator or Oracle Web Services Manager, all tasks described in "Installing and Setting Up Authentication Providers for OAM 10g" should be performed, including:

To configure Oracle Access Manager Identity Asserter for single sign-on with your application, perform the tasks as described in the following task overview.

Task overview: Deploying and configuring the Oracle Access Manager Identity Asserter for single sign-on includes

  1. Ensuring that all prerequisite tasks have been performed

  2. Establishing Trust with Oracle WebLogic Server

  3. Configuring the Authentication Scheme for the Identity Asserter

  4. Configuring Providers in the WebLogic Domain

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

  6. Testing Identity Assertion for SSO with OAM 10g

  7. Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates

17.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:

Note:

This task is the same for both OAM 11g and OAM 10g.

17.4.1.1 Setting Up the Application Authentication Method for SSO

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.

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

Note:

You can specify CLIENT-CERT, FORM if you are also planning to access the applications directly over WebLogic and want the WebLogic authentication scheme to be invoked.

To specify authentication in web.xml for the Identity Asserter and OAM 10g

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

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

17.4.1.2 Confirming mod_weblogic for Oracle Access Manager Identity Asserter

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 Identity Asserter and OAM 10g

  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 yourHost.yourDomain.com
         WebLogicPort yourWlsPortNumber
    </IfModule>
     
    <Location http://request-uri-pattern>
       SetHandler weblogic-handler
    </Location>
    
  3. Save the file.

  4. Proceed to "Establishing Trust between Oracle WebLogic Server and Other Entities".

17.4.1.3 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 topic is the same whether you are using OSSO or Oracle Access Manager.

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

Table 17-10 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 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 Authentication Scheme for the Identity Asserter".

17.4.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 "Session Token: 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 "Creating an Authentication Scheme, Policy Domain, and a WebGate Profile".

17.4.2.1 Creating an Authentication Scheme, Policy Domain, and a WebGate Profile

This topic provides a procedure that you can use as a model when you run OAMCfgTool.

This example presumes a fresh Web Tier that requires a new WebGate profile. Therefore, the web_domain= parameter is omitted. A new profile is created and named with the app_domain value (appended with _AG).

The following procedure is only an example to illustrate how to use the tool. Values for your environment will be different.

Note:

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

To create a form authentication scheme, policy domain, and access polices with OAMCfgTool

  1. No Oracle Fusion Middleware Application: Obtain the OAMCfgTool 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 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. Confirm that JDK 1.6 (or the latest version) is installed and configured.

  3. Log in to the computer that is hosting the application to protect, change to the file system directory containing OAMCfgTool.

    Note:

    • Fresh Web Tier: Omit web_domain parameter to create and associate a new a profile. Include the cookie_domain parameter.

    • Existing Web Tier: Include web_domain parameter with the value of an existing host identifier.

  4. Create a WebGate Profile, Authentication Scheme, and Policy Domain: Run the following command using values for your environment as described in Table 17-5. For example:

    (echo ldappwd | java -jar oamcfgtool.jar 
    mode=CREATE app_domain=IASSO_App1 
    protected_uris=/myapp/login 
    cookie_domain=<preferred_http_cookie_domain>
    ldap_host=wxyz
    ldap_port=6633
    ldap_userdn=orcladmin
    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>
    -noprompt 
    
  5. 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  : IASSO_App1
         Host Identifier: IASSO_App1
         Access Gate ID : IASSO_App1_AG
    
  6. Output LDIF Created: Import the LDIF to write information to the directory server. Otherwise, skip this step.

  7. Validate: Run OAMCfgTool to validate the policy domain that was created (see Table 17-7). For example:

    (echo ldappwd | java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1 
    protected_uris=/myapp/login
    ldap_host=wxyz
    ldap_port=6633
    ldap_userdn=orcladmin
    oam_aaa_host=abcd
    oam_aaa_port=7789
    log_file=OAMCfg_date.log
    log_level=INFO
    test_username=gcf
    test_userpassword=<test_userpassword> 
    -noprompt 
    
  8. Fresh WebGate Profile/WebGate Not Installed: Specify the same values when you install the WebGate as you specified when creating the profile (plus additional values to properly finish the installation).

  9. Fresh WebGate Profile with Installed WebGate: Using output from the OAMCfgTool Create command, run the Oracle Access Manager configureWebgate tool to set up the installed 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 profile. For example:

      configureWebGate -i WebGate_install_dir -t WebGate WebGate_Name -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 Access Manager Access Administration Guide

  10. 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 WebPass Web server; port refers to the HTTP port number of the WebPass 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 Access Manager Access Administration Guide.

  11. Repeat Steps 3 through 8 for each application that you are protecting.

  12. Proceed to "Configuring Providers in the WebLogic Domain".

17.4.3 Configuring Providers in the WebLogic Domain

This topic is divided as follows:

17.4.3.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 one 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 providers use token-based authentication; the Oracle Access Manager Identity Asserter is one example.

  • 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 the 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. You can choose the following the JAAS Control Flag settings, among others:

  • 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

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

17.4.3.2.1 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 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 OPSS 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

Command Syntax

addOAMSSOProvider(loginuri, logouturi, autologinuri)

Table 17-11 defines the expected value for each argument in the addOAMSSOProvider command line.

Table 17-11 addOAMSSOProvider Command-line Arguments

Argument Definition

loginuri

Specifies the URI of the login page

logouturi

Specifies the URI of the logout page

autologinuri

Specifies the URI of the autologin page


Prerequisites

Before starting this task, ensure that all previous tasks have been performed as described in:

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 this chapter:

  6. Run the application.

17.4.3.3 Setting Up Providers for Oracle Access Manager 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

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

    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 Authentication, 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, and click Save

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

      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:

17.4.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 17-9 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 17-9 Default Login Form for Single Sign-On with 10g WebGates

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

Note:

Do not alter any variables in this login form. Variables are required for use with Oracle Access Manager Identity Asserter.

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.

Note:

The Login form is for only 10g WebGates with OAM 10g.

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:

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

17.5 Configuring the Authenticator for Oracle Access Manager 10g

To configure the Oracle Access Manager Authentication Provider as the Authenticator, you must perform the tasks in this section.

Prerequisites

Unless explicitly labeled Identity Assertion, all tasks described in "Installing and Setting Up Authentication Providers for OAM 10g" must be completed:

Remaining tasks to configure the Oracle Access Manager Authenticator are described in the following task overview.

Note:

You must be either a Master or Delegated Access Administrator in Oracle Access Manager to perform tasks here. There is no tool available to automate tasks outside Oracle Access Manager.

Task overview: Configuring the Oracle Access Manager Authenticator includes

  1. Ensuring that all prerequisite tasks have been performed

  2. Creating an Authentication Scheme for the Authenticator

  3. Configuring a Policy Domain for the Oracle Access Manager Authenticator

  4. Configuring Providers for the Authenticator in a WebLogic Domain

  5. Configuring the Application Authentication Method for the Authenticator

  6. Mapping the Authenticated User to a Group in LDAP

  7. Testing the Oracle Access Manager Authenticator Implementation

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

17.5.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 17-10.

Figure 17-10 Create Policy Domain Page in the Oracle Access Manager Policy Manager

Image of the Create Policy Domain page
Description of "Figure 17-10 Create Policy Domain Page in the Oracle Access Manager Policy Manager"

For more information, see the following topics:

17.5.2.1 About Creating a Policy Domain

This topic describes the tabs in the Policy Manager that you use to enter details for your policy domain and access policies. While you might not use every tab in your policy domain, the following general information is provided:

  • General Tab: Enter a short alphanumeric string to name this policy domain. You can use spaces in the Name field. A description is optional. Do not enable this policy domain until all details are saved and you are ready to use the domain.

  • Resources Tab: Add resources to be protected by this policy domain. You use URL prefixes to define the policy domain content. A description is optional.

  • Authorization Rules Tab: specify an authorization rule that consists of general information, Allow Access and Deny Access conditions, and actions for the rule, if any, to be used in an Authorization Expression later. You must specify an authorization scheme for every authorization rule you define.

  • Default Rules Tab: Create default rules that apply to the resources protected by the policy domain, unless the resource is protected by a specific policy. From this tab you add the authentication rule, authorization expression, and audit rule for this policy domain.

    Authentication Rule: A policy domain must have at least one authentication rule, which specifies one authentication scheme and authentication actions.

    Authorization Expression: These include authorization rules and the operators used to combine them. The Authenticator function requires an Authorization rule that allows access by anyone.

    Audit Rule: If there is no Master Audit Rule defined, you are instructed to contact your Access System Administrator.

  • Policies Tab: If no rules are defined, the default rules for the policy domain remain in effect. For each policy you create, you can assign a specific authentication rule, authorization expression, and auditing rule. You can create policies with granular URL patterns. Before setting up a policy, decide the level of access control needed for the URL you to be protected.

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

See Also:

"Creating a Policy Domain and Access Policies for the Authenticator" and the following topics in the Oracle Access Manager Access Administration Guide:

  • "Creating an Authentication Rule for a Policy Domain"

  • "Creating an Audit Rule for a Policy Domain"

17.5.2.2 Creating a Policy Domain and Access Policies for the Authenticator

The Authenticator implementation requires several default and some unique values in the policy domain. You must be a Master or Delegated Access Administrator in Oracle Access Manager to create, view, or modify a policy domain.

In the following procedure, you create a policy domain for the Authenticator to:

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

  • Protect resources of type wl_authen, which was defined earlier. See also, "Creating Resource Types in Oracle Access Manager 10g"

  • Request user credentials using the Oracle Access Manager authentication scheme created earlier.

    Note:

    The Authenticator requires the BASIC authentication method defined in the application web.xml file, which you will set up later as described in "Configuring the Application Authentication Method for the Authenticator".

  • Require a default authentication rule and actions, which you configure in the following procedure to return users and groups on authentication success.

  • Require a default authorization rule with no actions, which you configure in the following procedure to allow access by anyone.

    Note:

    The Authenticator does not perform authorization. However, you must create the authorization rule to allow access by anyone (but no authorization expression is required).

Examples in the following procedure are for illustration only. Be sure to enter appropriate values for your environment.

To create a policy domain for the Oracle Access Manager Authenticator

  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.

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

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

    Name: Default OAM Authenticator

    Description: For Username Resolution

    Note:

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

  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

    Host Identifier (optional): Select the Preferred HTTP host for the AccessGate.

    URL prefix: /Authen/Basic

    Description: OAM Authenticator validates user name, password

    Click Add.

    Resource Type: wl_authen

    URL prefix: /Authen/UsernameAssertion

    Description: Authenticator Resource to validate user name

    Click Save.

  6. Default Rules Tab: From this tab you add the authentication rule, authorization expression, and audit rule for this policy domain. The policy domain's default rules apply to the resources it contains, unless the resource is protected by a specific policy.

    1. Click Default Rules, and then click Add to create the rule for the Basic Authentication scheme.

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

      Click Authentication Rule and fill in the General tab as follows.

      Name: Basic Authentication Scheme

      Description: User name and password based authentication

      Authentication Scheme: Basic over LDAP

      Click Save.

      Note:

      For the Authenticator you need only an Authentication Success Return Action in the rule for the ObMyGroups attribute. This Access Server-specific attribute returns all the groups to which the user belongs. Two other implementations require this action, as described in Step C.

    3. Authentication Rule, Actions: For the Authenticator (or to boot Oracle WebLogic with Administrator users who exist in Oracle Access Manager, or if you are using Oracle Web Services Manager).

      Click the Actions tab, click Add.

      Enter the following for Authentication Success:

      Redirection URL: Leave blank

      Return

      Type: WL_REALM

      Name: obmygroups

      Return Attribute: obmygroups

      This return attribute directs the Access Server to return all groups to which the user belongs.

      Next, enter the name of the login parameter for user name to help in identifying the user uniquely in the LDAP directory server

      Type: WL_REALM

      Name: uid

      Return Attribute: uid

      This return attribute should be the name of the login parameter for the user name. This helps in identifying the user uniquely in the LDAP directory server used by Oracle Access Manager.

  7. Authorization Rule: Click the Authorization Rules tab, click Add and:

    1. Specify a rule name and, optionally, a brief description. For example:

      Name: Default rule for Authenticator.

      Description: Default rule enables Authenticator function for anyone.

    2. Select Yes from the Enabled list and then click Save.

    3. Click the rule, click the Allow Access tab, click Add, Under Role, select Anyone to allow anyone access to the protected resources.

    4. Click Save.

  8. Policies Tab: Click the Policies tab, click Add.

    Fill in and save General details:

    Name: Default Username Resolution Policy

    Description: Default Username Policy for Authenticator

    Resource Type: wl_authen

    Resource operation(s): LOGIN

    Resource: /Authen/UsernameAssertion

    Leave other items as they are.

    Click Save.

    Click the Authentication Rule sub tab, click Add, and fill in General details (Name, optional Description, Authentication Scheme).

    Name: Username Resolution Authentication Rule

    Authentication Scheme: UsernameAssertion Authentication Scheme

    See "Creating an Authentication Scheme for the Authenticator".

    Click Save.

    Click the Actions sub tab and add the following details for Authentication Success:

    • Return Type: WL_REALM

    • Return Name: uid

    • Return Attribute: uid

      Note:

      Be sure to enter Return Attribute. uid is the name of the login attribute in the LDAP ObjectClass that helps to identity the user uniquely in the directory server used by Oracle Access Manager.

    Click the Actions sub tab and add the following details for Authentication Success:

    • Return Type: WL_REALM

    • Return Name: obmygroups

    • Return Attribute: obmygroups

    Note:

    obmygroups returns all groups to which a member belongs.

  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 Access Manager Access Administration Guide, "Delegating Policy Domain Administration"

  10. Proceed with "Configuring Providers for the Authenticator in a WebLogic Domain".

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

Note:

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

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

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

17.5.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:

17.5.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 Access Manager Access Administration Guide.

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.

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

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

When the Oracle Access Manager Identity Asserter is configured for both header and ObSSOCookie token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the Access Server to validate the ObSSOCookie token.

Oracle Access Manager Identity Asserter works in two modes:

Prerequisites

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

  1. Ensuring that all prerequisite tasks have been performed

  2. Creating an Policy Domain for Use with Oracle Web Services Manager

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

  4. Testing the Identity Asserter with Oracle Web Services Manager

17.6.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 Access Manager Access Administration Guide 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 Access Manager Access Administration Guide, "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 Providers in a WebLogic Domain for Oracle Web Services Manager".

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

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

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

17.7 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the 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 make sure 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 17-12.

Table 17-12 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".

17.8 Troubleshooting Tips for OAM Provider Deployments

This section contains the following topics:

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

See Also:

Oracle Fusion Middleware Administrator's Guide for details about using IPv6.

17.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_HOME/config/OHS/<ohs_name>/httpd.conf
    
    <IfModule mod_weblogic.c>
                 WebLogicHost yourHost.yourDomain.com
                   WebLogicPort yourWlsPortNumber
              </IfModule>
    

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

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

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

17.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 Access Manager Access Administration Guide

    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 Access Manager Access Administration Guide.

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

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

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

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

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

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

  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.

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

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

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

17.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_HOME/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>
    

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

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

17.8.18 About Protected_JSessionId_Policy

OAM Policies are evaluated based on the URIs passed to it. With earlier releases, there was no policy for protecting *;jsessionid*. When an application resource URL was accessed and the JSESSIONID cookie was not found, WebLogic Server wrote the URL by including the JSESSIONID as part of the URL. If the URL in question was protected, Oracle Access Manager and OSSO Web agents could have issues matching the re-written URL.

In this release, a new policy is available that uses a pattern "*;jessionid=*" for all URIs under the context-root. Therefore, any URI under the context-root, with ";jsessionid=string" appended to it, is considered protected.

The /context-root itself must be listed as a resource. The URL pattern is *;jsessionid=*. The Default authentication rule is a protected authenticating scheme. The Default authorization expression is also used. When ordering policies, this policy must be first.

Suppose you have one protected resource named /test/protectedUri and a public resource named /test. When you create a public policy with the pattern *jessionid;* and apply this policy to both the above resources the public policy should have precedence over the public resource.

  • When /test;jessionid=blah is requested, OAM first checks for a default rule for "/test;jessionid=blah". Without such a rule, OAM then checks for a rule for "/". Without this rule, the URI, "/test;jessionid=blah" is considered to be unprotected.

  • When "/test/protectedUri;jessionid=blah" is requested, OAM checks for a default rule to protect this. Without such a rule, OAM then checks for a rule for "/test". With "/test" in the Resources list, OAM further determines which policy to apply. In this case, the jessionid policy is applied and the request deemed to be protected.