23 Understanding Credential Collection and Login

Access Manager credential collection is a functionality that can be executed either on the Access Manager server (ECC) or WebGates (DCC).

This chapter includes the following topics:

• Overview of Access Manager Credential Collection

• Overview of the SSO Login Process with OAM Agents and ECC

• Overview of the SSO Login Process with OAM Agents and DCC

• Configuring OAM WebGate and Authentication Policy for DCC

• Tunneling from DCC to Access Manager Over Oracle Access Protocol

• Configuring a DCC WebGate for X509 Authentication

Note:

Unless explicitly stated, information in this chapter is the same for all agent types and Access Manager credential collectors.

See Introduction to Centralized Logout for Access Manager.

23.1 Overview of Access Manager Credential Collection

Access Manager provides two mechanisms for credential collection during authentication processing.

• The default Embedded Credential Collector (ECC) is installed with the Access Manager Server and can be used as-is with no additional installation or set up steps (except the global password policy configuration described in "Managing Global Password Policy").

  The mechanism that redirects the user from the Policy Enforcement Point to the Credential Collector is a proprietary front channel protocol over HTTP. This protocol currently provides a context of the request and the authentication response on the query string.

• The OAM WebGate provides a single switch for the optional Detached Credential Collector (DCC). The DCC allows termination of end-user requests in the Web Tier as opposed to the Application Tier.

Note:

• It is recommended that you use ECC for the new features introduced in OAM 12c. Some of the new features introduced in OAM 12c do not support DCC. For example, OpenIDConnect with DCC is not supported.
• ECC and DCC both allow for a secure deployment where a Defense in Depth approach requires that security vulnerabilities (DDOS, Throttling, Application Firewalling) be handled in the upstream application delivery tier. For typical Enterprise deployments, robust upstream capabilities exist, making any potential benefit of terminating unauthenticated connections on the Web Tier very minimal, given the limitations with DCC.

For a detailed comparison of the two mechanisms for credential collection, see Understanding Authentication Methods and Credential Collectors.

Single Sign On login processing determines whether the user is a valid user and whether the session state is active or inactive (either a first time user or the user session has expired). Session management support locates, persists, and cleans up the session context and user token. Details are in the following sections.

• Overview of the Login process with Self-Service Provisioning Applications

• Overview of the Login Process with Access Manager-Protected Resources

23.1.1 Overview of the Login process with Self-Service Provisioning Applications

Provisioning does not create the session in Access Manager. When a new user uses a self-service provisioning application to create an account, he is prompted for his userID and password again when accessing an application.

The protected application is directed to Access Manager, which requests the user's credentials. For example, if Oracle Identity Governance is protected by Access Manager, the user request is redirected to Access Manager from which a request to enter credentials is made.

Note:

Success and failure results are the same as described in "Overview of the Login Process with Access Manager-Protected Resources".

23.1.2 Overview of the Login Process with Access Manager-Protected Resources

The first time a user attempts to access a protected resource, she is prompted for her credentials based on the authentication scheme and authentication level for the resource. Typically a userID and password are needed.

Failure: Authentication fails if the wrong userID or password is entered. The user is not authenticated and another prompt for credentials appears.

With Oracle Access Manager, only the ECC in the OAM server was available. Access Manager supports the ECC by default. However, Access Manager also enables you to configure an OAM WebGate to use as a detached credential collector (DCC). A DCC-enabled WebGate can be separate from (or combined with) a Resource WebGates.

Both the ECC and DCC provide an authentication flow that includes form login, error, and login retries. They provide SecurID and server affinity as well as password policy enforcement and a dynamic, multi-step, iterative, and variable (multi-step authentication) where the credentials are not supplied all at one time. A customizable authentication flow can include authentication plug-ins with contracts between the plug-in, OAM Proxy, and Credential Collector; a contract between the plug-in and login application; and between the Credential Collector and login application.

When deciding whether to use one credential collector or both, consider:

• Co-existence: Allowing both the ECC and DCC to co-exist enables you to use authentication schemes and policies configured for either the ECC or the DCC. This enables a fallback mechanism for resources that rely on the ECC ( Oracle Access Management Console, for instance).

• Disabling ECC: Disabling the ECC entirely prohibits access to resources that rely on the ECC mechanism ( Oracle Access Management Console, for instance).

Table 23-1 provides links to more information.

Table 23-1 Login Processing with Access Manager-Protected Resources

Login Processing Topic	See
With OAM Agents and ECC	"Overview of the SSO Login Process with OAM Agents and ECC"
With OAM Agents and DCC	"Overview of the SSO Login Process with OAM Agents and DCC"
With Other Agents or Mixed Agent Types	Mixed agent types are supported. Processing is the same for each agent type.
Login and Auto Login for Applications Using Oracle ADF Security	Oracle Platform Security Services (OPSS) comprise Oracle WebLogic Server's internal security framework. On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Access Manager SSO, and uses OPSS SSO for user authentication. For more information, see Integrating Oracle ADF Applications with Access Manager SSO.

23.2 Overview of the SSO Login Process with OAM Agents and ECC

Access Manager authenticates each user with a customer-specified authentication method to determine the identity and leverages information stored in the user identity store.

This topic is based on using the default Embedded Credential Collector with OAM Agents (Resource WebGates) protecting resources.

Access Manager authentication supports several authentication methods and a number of authentication levels. Resources with varying degrees of sensitivity can be protected by requiring higher levels of authentication that correspond to more stringent authentication methods.

When a user tries to access a protected application, the request is received by Access Manager which checks for the existence of the SSO cookie.

After authenticating the user and setting up the user context and token, Access Manager sets the SSO cookie and encrypts the cookie with the SSO Server key (which can be decrypted only by the SSO Engine).

Depending on the actions (responses in Access Manager 11g) specified for authentication success and authentication failure, the user may be redirected to a specific URL, or user information might be passed on to other applications through a header variable or a cookie value.

Based on the authorization policy and results of the check, the user is allowed or denied access to the requested content. If the user is denied access, she is redirected to another URL (specified by the Administrator in WebGate registration).

Figure 23-1 shows the processes involved in evaluating policies, validating a user's identity, authorizing the user for a protected resource, and serving the protected resource. This example shows the OAM Agent flow. There are slight variations with 12c WebGates/Access Clients.

Figure 23-1 SSO Log-in with Embedded Credential Collector and OAM Agents

Description of "Figure 23-1 SSO Log-in with Embedded Credential Collector and OAM Agents"

Process overview: SSO Login Processing with Embedded Credential Collector and OAM Agents

1. The user requests a resource.

2. WebGate forwards the request to Access Manager for policy evaluation.

3. Access Manager:

   • Checks for the existence of an SSO cookie.

   • Checks policies to determine if the resource protected and if so, how?

4. Access Manager Server logs and returns decisions.

5. WebGate responds as follows:

   1. Unprotected Resource: Resource is served to the user.

   2. Protected Resource:

      Request is redirected to the credential collector.

      The login form is served based on the authentication policy.

      Authentication processing begins

6. User sends credentials.

7. Access Manager verifies credentials.

8. Access Manager starts the session and creates the following host-based cookies:

   • One per Agent: OAMAuthnCookie set by OAM WebGates using the authentication token received from the OAM Server after successful authentication.

     Note: A valid cookie is required for a session.

   • One for OAM Server: OAM_ID

9. Access Manager logs Success or Failure.

10. Credential collector redirects to WebGate and authorization processing begins.

11. Webgate prompts Access Manager to look up policies, compare the user's identity, and determine the user's level of authorization.

12. Access Manager logs policy decision and checks the session cookie.

13. OAM Server evaluates authorization policies and cache the result.

14. OAM Server logs and returns decisions

15. WebGate responds as follows:

    • If the authorization policy allows access, the desired content or applications are served to the user.

    • If the authorization policy denies access, the user is redirected to another URL determined by the Administrator.

23.3 Overview of the SSO Login Process with OAM Agents and DCC

The detached credential collector is simply a WebGate configured to use the additional Credential Collection capability in your deployment.

There are two deployment types depending on whether the DCC WebGate is also protecting the applications or not.

Table 23-2 identifies the DCC-supported deployments.

Table 23-2 DCC Deployment Support

Deployment Type	Description
Separate DCC and Resource Webgate	A distributed deployment where WebGates protecting applications are managed independently from the centralized DCC. You can have: Two or more Resource Webgates that redirect to the DCC-enabled WebGate for authentication Enable HTTPS between the user-agent and the DCC (but not with some or all Resource WebGates). When credential collection is externalized and centralized in the DCC, the user-agent connections with other WebGates never carry user credentials, nor session tokens that could be used to obtain access to resources protected by any other WebGate. This significantly reduces exposure caused by lack of SSL on these links and may be an acceptable tradeoff in some deployments. Separate OHS Instances: Install the DCC on a different OHS instance (on the same or different host) as the Resource WebGate. Define the Resource WebGate Authentication Scheme Challenge Redirect URL to point to the DCC. Define the Resource WebGate logoutRedirectUrl to point to the DCC logout script/page (logout callbacks to Resource WebGate is invoked during logout). See Also: Figure 23-2
Combined DCC and Resource Webgate	A streamlined deployment minimizing configuration and processing overhead. A DCC WebGate can function as both a resource WebGate (Policy Enforcement Point) that protects application resources and a DCC. In this case, there is no front-channel redirection or processing: Install the DCC on a the same OHS instance (on the same host) as the Resource WebGate. Simplified configuration: The Challenge Redirect URL can be empty. No logoutRedirectUrl is needed, no logout callback is needed. See Also: Figure 23-3

Separate DCC and Resource Webgates: A sample deployment with segregated DCC is shown in Figure 23-2.

Figure 23-2 Example: Separate Resource WebGate and DCC WebGate Deployment

Description of "Figure 23-2 Example: Separate Resource WebGate and DCC WebGate Deployment "

This topology (Figure 23-2) showcases choices appropriate for scenarios with maximum security sensitivity. Both centralized and externalized credential collection are used: Resource WebGates protecting applications are segregated from the DCC WebGate performing credential collection.

The user accesses the Access Manager-protected resource from the public network. A WebGate protecting the application is deployed within a DMZ. The DCC WebGate is also deployed within a DMZ. The protected application and OAM Server instances are located within the private network and not directly accessible from the public network.

Using the DCC in the DMZ, only authenticated network connections are allowed to reach the server itself. The DCC inherits all back-channel communication characteristics available to OAM WebGates (network connection using the Oracle Access Protocol). The OAP offers:

• SSL between the client and the server, optionally using 3rd party signed certificates

• mutual authentication at the application level using client id and password

• request multiplexing and full-duplex communication at the application level

• built-in connection load balancing and failover capability

The DCC receives an authentication request from the Agent and checks for the presence of the DCC cookie. If the cookie does not exist, credential collection is initiated; checks are made, and user-supplied credentials are passed for validation.

Note:

Encryption occurs only from resource WebGate to the DCC. The channel is not encrypted for communication between resource WebGate and DCC; this is in clear text.

Figure 23-3 Combined DCC and WebGate Configuration

Description of "Figure 23-3 Combined DCC and WebGate Configuration"

Process overview: Authentication with the combined DCC and Resource Webgate

1. The user requests access to a resource which initiates the authentication process.

2. The DCC redirects through the front channel to the login page.

3. The login page is returned to the user.

4. User enters credentials, which are posted to the action URL (a user-defined parameter in an authentication scheme, Table 22-25).

5. Authentication occurs using the back channel (OAP) and OAM Proxy.

6. The Authentication Plug-in is activated.

7. The Plug-in requests redirect to a URL to collect additional credentials.

8. The Plug-in request is returned to the DCC.

9. The DCC redirects to the URL and expects specified credentials.

10. The Browser follows the redirect.

11. Credentials are posted to the Action URL.

See Also:

"Configuring Logout When Using Detached Credential Collector-Enabled WebGate"

23.4 Configuring OAM WebGate and Authentication Policy for DCC

Administrators can enable DCC credential operations, update DCC forms for password policy, add PasswordPolicyValidationScheme to Authentication Policy, and use DCC for converged Federation flows.

The following steps describe configuring a WebGate and Authentication Policy for use with the DCC. The appropriate sub sections are linked within each step.

1. Enabling DCC Credential Operations provides steps for either configuration:

   DCC Combined with Resource Webgate: Enable Allow Credential Collector Operations in the DCC's OAM Agent registration page.

   Separate DCC and Resource Webgate: Enable Allow Credential Collector Operations in the DCC's OAM Agent registration page and edit the Resource Webgate registration page to set the Logout Redirect URL to the DCC's logout.pl.

2. Locating and Updating DCC Forms for Password Policy
3. Adding PasswordPolicyValidationScheme to Authentication Policy for DCC provides steps for either configuration:

   DCC Combined with Resource Webgate: In the combined DCC/Resource Webgate Application Domain, update the Protected Resources Authentication Policy to use your DCC Authentication Scheme.

   Separate DCC and Resource Webgate: In the separate Resource Webgate Application Domain, update the Protected Resources Authentication Policy to use your DCC Authentication Scheme.

4. Supporting Federation Flows With DCC provides steps to incorporate the DCC into Federation flows.

Note:

If your environment uses the ECC, See Completing Password Policy Configuration.

23.4.1 Enabling DCC Credential Operations

Whether you are using a separate DCC or combined DCC and Resource WebGate, you must enable Allow Credential Collector Operations in the DCC's OAM Agent registration page.

With a separate DCC and Resource WebGate, you must also edit the Resource WebGate registration page to set the Logout Redirect URL to the DCC's logout.pl, as described in Step 3.

The following procedure presumes your deployment uses Open mode communication. If your deployment uses Simple or Cert mode communication, be sure to copy the appropriate artifacts when you perform Step 4.

Prerequisites

• Configuring and Managing Registered OAM Agents Using the Console

• Managing Global Password Policy

• Configuring Password Policy Authentication using DCC-specific details

1. In the Access Manager section of the Oracle Access Management Console, click SSO Agents to find and open the registration page for the OAM Webgate that will function as the DCC.
2. DCC WebGate Registration: Check Allow Credential Collector Operations, change Token Validity Period to match the globally configured Session Lifetime value. Click Apply and then perform Steps 4 and 5.

   Note:

   If the DCC is combined with a Resource WebGate, skip Step 3.
3. Separate Resource WebGate: Edit the Resource WebGate registration to set the Logout Redirect URL to the DCC's logout.pl (Table 24-3), click Apply, then perform Steps 4 and 5.
4. Copy Agent configuration file (including Simple or Cert mode files) from the AdminServer (Console) host to the Agent host. For example:

   Agent & Artifacts	Artifacts
   OAM WebGate/Access Client ObAccessClient.xml and cwallet.sso	From the AdminServer (Console) host: $DOMAIN_HOME/output/$Agent_Name/ To the Agent host: $12cWG_install_dir/webgate/config
   Simple or Cert Mode	Copy to the Agent host: $12cWG_install_dir/webgate/config aaa_key.pem aaa_cert.pem aaa_chain.pem password.xml See Also: Securing Communication

5. Restart the OHS Web server.
6. Proceed to "Locating and Updating DCC Forms for Password Policy".

23.4.2 Locating and Updating DCC Forms for Password Policy

Access Manager provides several dynamic pages for user interactions with the DCC.

See Also:

Developing Applications with Oracle Access Management

Prerequisites

Enabling DCC Credential Operations

1. Locate the DCC forms in the WebGate host (Table 24-3): $WEBGATE_HOME/webgate/ohs/oamsso/*, $WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl, and $WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*.
2. Customize their location, depending on the desired topology of the authentication scheme being developed.
3. Update Perl Location: Update the Perl location to be consistent with the actual location, in the first line of the login, logout, and securid scripts on Webgate host in $WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl (Table 24-3).
4. Customize the default pages for your enterprise, or replace them entirely with custom pages. For example, you can design, implement, and deploy a custom page that displays a different version of the login form for a mobile browser than is used for a desktop browser.
5. Proceed to "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC".

23.4.3 Adding PasswordPolicyValidationScheme to Authentication Policy for DCC

You can use your DCC Authentication Scheme in a Protected Resources Authentication Policy.

The steps you perform depend on the type of deployment you have:

• Combined DCC/Resource WebGate: Perform Step 1 to add your DCC Authentication Scheme to the Protected Resources Authentication Policy of the combined DCC/Resource WebGate Application Domain.

• Separate Resource WebGate: Perform Step 3 to add your DCC Authentication Scheme to the Protected Resources Authentication Policy of the separate Resource WebGate Application Domain.

Perform Step 2 regardless of your DCC deployment type. By default, login and logout forms are excluded through OHS /httpd.conf/webgate.conf so that you do not need to exclude them through policies. However, with the Chrome browser, you must explicitly exclude the async favicon.ico request (which overrides the DCCCtxCookie).

Note:

This example refers to the PasswordPolicyValidationScheme set for the DCC in Configuring Password Policy Authentication.

Prerequisites

Locating and Updating DCC Forms for Password Policy

1. Combined DCC/Resource WebGate: Open the DCC application domain:

   • Policy Configuration
   • Application Domains
   • DCCDomain

   1. Locate and open the Authentication Policy, Protected Resource Policy (see "Searching for an Authentication Policy").

   2. Add your DCC Authentication Scheme to this policy (see "Defining Authentication Policies for Specific Resources").

      • PasswordPolicyValidationScheme (DCC Authentication Scheme)

   3. Perform Step 2 if you have the Chrome Browser. Otherwise, go to Step 4.

2. Chrome Browser: Add and exclude resource /favicon.ico in the DCCDomain, as follows.

   1. From DCCDomain, click the Resources tab.

   2. Find and open the HTTP resource /favicon.ico (or click the New Resource button and then add this resource).

   3. Confirm or edit the Resource URL to:

      /favicon.ico
      

   4. In the Protection section, Protection Level list, select Excluded, then click Apply.

   5. Proceed to Step 4.

3. Separate Resource Webgate: Open the Resource Webgate application domain.

   • Policy Configuration
   • Application Domains
   • ResourceWGDomain

   1. Locate and open the Authentication Policy, Protected Resource Policy (see "Searching for an Authentication Policy").

   2. Add your DCC Authentication Scheme and an optional Failure URL (when not specified, Failure URL displays the default error page) to this policy (see "Defining Authentication Policies for Specific Resources"):

      • DCC Authentication Scheme
      • Failure URL (optional)

   3. Perform Step 2 if you have the Chrome Browser. Otherwise, go to Step 4.

4. Restart your Web server and proceed to "Completing Password Policy Configuration".

   See Also:

   "Configuring Logout When Using Detached Credential Collector-Enabled WebGate"

23.4.4 Supporting Federation Flows With DCC

The DCC is enhanced to work as a public end-point to the Access Manager server. HTTP requests to the DCC are tunneled through NAP to the proxy module of the Access Manager server. Only requests defined in the TunneledUrls parameter of the DCC Profile will be tunneled. The JSP pages and servlets are executed in the Access Manager server and the response is tunneled back to the DCC. The end user effectively communicates only to the DCC.

Note:

If a WebGate is configured as a DCC and federated flows are in use, the DCC WebGate cannot be used to protect the resource. A separate WebGate must be configured and used to protect the resource. Authentication and authorization requests will be tunneled to the OAM Server, and the ECC login form will be tunneled and displayed in the user's browser.

To use DCC for converged Federation flows, perform the following manual steps.

1. Configure the following internal resources as Public instead of Excluded.

   /oamfed/.../*
   /oam/.../*
   /.../*
   

2. In the DCC WebGate, set the logout value to a valid DCC WebGate logout URL; for example, /oamsso-bin/logout.pl
3. Update the DCC Agent entry by adding the following entry to the User Defined Parameters list using the Access Manager Administration Console.

   TunneledUrls=/oam,/oamfed
   

   See Configuring OAP Tunneling.

4. Update the OAM public endpoint entry so that it points to the DCC WebGate.

   Under Access Manager Settings, set the OAM Server Host, OAM Server Port and OAM Server Protocol to the values pertinent to the OHS/DCC and click Apply.

   Note:

   Alternately you can update a single Authentication Scheme to point to the DCC WebGate by altering the challenge redirect URL leaving the REST parameters unchanged.

5. Update the ProviderID value under Federation Settings (if applicable) and redistribute the new metadata to all Federation partners due to the endpoint change.
6. Set the contextType to 'External'.

   See Authentication Schemes and Pages for details on this setting.

23.5 Tunneling from DCC to Access Manager Over Oracle Access Protocol

Access Manager supports HTTP communication over the Oracle Access Protocol (OAP). In this case, a WebGate configured as a DCC uses the ECC servlets for credential collection during Access Manager authentication.

The following sections contain more details.

• How DCC Tunneling with OAP Works

• Configuring OAP Tunneling

Note:

For details on the DCC, see Embedded Credential Collector Versus Detached Credential Collector.

23.5.1 How DCC Tunneling with OAP Works

The tunneling process works for DCC WebGates only.

Figure 23-4 illustrates how the tunneling process works.

Figure 23-4 OAP Tunneling with DCC

Description of "Figure 23-4 OAP Tunneling with DCC"

The following steps provide more details in regards to the OAP Tunneling process.

1. The URL to be tunneled is configured in the DCC WebGate profile.

2. This same URL is mapped to a servlet or JSP page in the Access Manager server.

3. On accessing the tunneled URL, the WebGate intercepts the HTTP request and converts it to an OAP request.

4. The OAP request is forwarded to the Access Manager server.

5. The Access Manager server (OAM proxy) receives the OAP request and passes it to the tunnel proxy.

6. The tunnel proxy will convert the OAP request to an HTTPServletRequest and invoke the corresponding servlet (or compiled servlet in the case of a JSP).

7. The response is converted back to an OAP message and passed to the OAP end point.

8. The OAM end point responds to the WebGate with the converted OAP message.

9. The WebGate converts the OAP message back to an HTTP response.

10. The WebGate provides the HTTP response to the caller (browser).

23.5.2 Configuring OAP Tunneling

To configure OAP Tunneling, a WebGate must be installed and configured to work with the Access Manager server as a DCC.

The Access Manager endpoint must be deployed on the Access Manager Server. After ensuring these prerequisites have been met, add a user-defined parameter to the WebGate profile that defines all URLs to be tunneled using the form TunneledUrls=<URL>,<URL1>. For example:

TunneledUrls=/oam,/sampleapp

Lastly, protect the Tunneled URLs with an Authentication Policy. For details, see Managing Authentication and Shared Policy Components.

23.6 Configuring a DCC WebGate for X509 Authentication

Configure a WebGate for DCC and convert it to SSL for using it with X509 authentication.

1. Configuring the WebLogic Server

2. Configuring a WebGate For DCC

3. Converting the DCC WebGate to SSL

23.6.1 Configuring the WebLogic Server

Use the procedures in the following sections to configure a WebLogic Server for X509 authentication.

1. Creating the Server and Trust Store

2. Configuring the WebLogic Server Instance

3. Creating the User Certificate

4. Adding the Root CA Certificate

23.6.1.1 Creating the Server and Trust Store

These are common procedures for WebLogic Server.

1. Create Server certificate

   Create a Server Certificate and key for the WLS domain on which Oracle Access Management 11g is deployed. This entails requesting a certificate (in which the Common Name is the OAM server machine name), having the certificate signed and converting it to the P12 format. The Server certificate can be created and signed using any Certificate utility.

2. Create the server store and the trust store using keytool.

   See Securing Communication Between OAM Servers and WebGates for details.

23.6.1.2 Configuring the WebLogic Server Instance

Use the WebLogic console to configure the instance of the WebLogic Server to be SSL and client certificate enabled.

1. Navigate to the server instance which is to be SSL and Client Cert enabled.

   Figure 23-5 Enable SSL

   
   Description of "Figure 23-5 Enable SSL"
2. Check the SSL Listen Port Enabled check box and provide the port number as in Figure 23-5.
3. Provide the server and trust keystore path under the “Keystore" tab.

   Figure 23-6 Keystore Configuration

   
   Description of "Figure 23-6 Keystore Configuration"
4. Add the private key alias details under the SSL tab.

   The alias name is same name specified as the server store name in Creating the Server and Trust Store.

   Figure 23-7 Add Private Key Alias

   
   Description of "Figure 23-7 Add Private Key Alias"
5. Display the Advanced options under the SSL tab and make the configurations illustrated in Figure 23-8.

   Figure 23-8 SSL Advanced Options

   
   Description of "Figure 23-8 SSL Advanced Options"

23.6.1.3 Creating the User Certificate

You can create a user certificate in the .p12 format and install it in your browser.

Run the following OpenSSL commands:

1. openssl req -config openssl.cnf -new -out weblogic.csr

   Provide the certificate details. The Common Name is the name of the user for whom the certificate is requested.

2. openssl x509 -req -md5 -CAcreateserial -in weblogic.csr -days 180 -CA

   F:\openssl\simpleCA\ca.pem -CAkey F:\openssl\simpleCA\ca-key.pem -extfile

   F:\openssl\openssl.cnf -out weblogic.pem

3. openssl rsa -in privkey.pem -out weblogic.key
4. openssl pkcs12 -export -in weblogic.pem -inkey weblogic.key -out user1k1.p12
5. Install the .p12 formatted certificate output in your browser.

23.6.1.4 Adding the Root CA Certificate

You can add the Root CA certificate of the certificate utility used to SSL enable the WebLogic server.

(In this example, the OpenSSL certificate utility is used.) The Root CA certificate must be added to the .oamkeystore and amtruststore files located in the following WebLogic directory:

$DOMAIN_HOME/base_domain/config/fmwconfig

1. Retrieve the password for the .oamkeystore and amtruststore files in WebLogic.

   1. Navigate to $MIDDLEWARE_HOME/Oracle_IDM1/common/bin/.

   2. Run wlst.sh.

   3. Run connect() in the WLST shell.

   4. Run domainRuntime() in the WLST shell.

   5. Run listCred(map="OAM_STORE",key="jks") in the WLST shell to display the password.

2. Add the Root CA certificate to the .oamkeystore and amtruststore files using the keytool command.

   The value of –storepass is the password retrieved in the previous step. For example:

   ./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore /scratch/Oracle/Middleware/user_projects/domains/base_domain/config/fmwconfig/.oamkeystore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jceks
    
   ./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore /scratch/Oracle/Middleware/user_projects/domains/base_domain/config/fmwconfig/amtruststore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jks
   

23.6.2 Configuring a WebGate For DCC

You can configure a WebGate for DCC. As part of this procedure you will also create the LDAPScheme_DCC Authentication Scheme.

You will use the Oracle Access Management Console for the configuration steps. This procedure assumes you have already installed the WebGates for which you will be creating profiles.

1. Configure an OAM WebGate profile named, for example, ABC_WG1 on http://<host>:7778/index.html.

2. Configure an OAM WebGate profile named, for example, XYZ_WG1_DCC on http://<host>:7779/index.html.

   This WebGate will act as the authentication WebGate.

3. Navigate to the XYZ_WG1_DCC WebGate profile and Select Allow Credential Collector Operations Option.

   This configures the WebGate for use as a DCC.

4. Create a new Authentication Scheme by making a copy of the LDAPScheme Authentication Scheme and modifying the following values.

   Only modify the following values; leave the other parameters untouched.

   1. Name as LDAPScheme_DCC

   2. Challenge redirect URL is http://<host>:<port>/ (http://<host>:7779/)

   3. Challenge URL : /oamsso-bin/login.pl

5. Navigate to the ABC_WG1 Application Domain and do the following.

   1. Go to Authentication Policy.

   2. Select Authentication Policy (Protected Resource Policy).

   3. Select the newly created Authentication Scheme LDAPScheme_DCC.

6. Restart the Oracle HTTP Server with port 7779 in use.

7. Access the protected resource at http://<host>:7778/index.html.

   You should get challenge page from the authenticating WebGate server (port 7779). After providing valid credentials, the resource on the port 7778 server should be displayed.

23.6.3 Converting the DCC WebGate to SSL

You can convert the DCC WebGate instance to SSL.

The following sections have details.

• Generating Server Certificates

• Generating and Importing Client Certificates

23.6.3.1 Generating Server Certificates

You can generate server certificates using Oracle Wallet Manager (OWM).

1. Create a Wallet using OWM.

   1. Start OWM.

      $ <webtier>/bin/owm
      

   2. Select Wallet > New and follow the on screen instructions to create a Certificate Request.

   3. Save the created Wallet in an accessible location and write down the path for future reference.

   4. Select the Auto Login option and save the Wallet again.

2. Create and export the server request file as server.csr using OWM.

   1. Select Operations > Export Certificate Request.

   2. Save as server.csr

3. Sign server.csr to generate user certificate server.pem.

   You can use the OpenSSL utility as follows:

   openssl x509 -req -md5 -CAcreateserial -in ohs_server.csr -days 3656 -CA /
     <path>/ca.pem -CAkey /<path>/ca-key.pem -out server.pem
   

   The values of ca.pem and ca-key.pem should be the same ones used when generating the client certificate.

4. Import the CA certificate (ca.pem) into OWM.

   1. Select Operations > Import Trusted Certificate.

   2. Point to ca.pem, your CA certificate.

   3. Import the CA certificate and save the wallet.

5. Import server.pem as user cert

   1. Select Operations > Import User Certificate.

   2. Point to the server.pem certificate generated in step 3.

   3. Import the server certificate and save the wallet.

6. Edit the Oracle HTTP Server (OHS) ssl.conf file to point to this wallet as follows.

   #Path to the wallet
   SSLWallet "/<path to wallet>/wallet"
   SSLVerifyClient require
   

   ssl.conf is located at <webtier>/<instance_home>/config/ohs/ssl.conf.

7. Restart the OHS instance.

23.6.3.2 Generating and Importing Client Certificates

You can generate and import client certificates and create a new X509 authentication scheme.

1. Create a user certificate by following the steps documented in Creating the User Certificate.
2. Create a new Authentication Scheme named X509_DCC as illustrated in Figure 23-9.

   Add a Challenge Redirect URL. The Challenge URL should be blank.

   Figure 23-9 New X509 Scheme

   
   Description of "Figure 23-9 New X509 Scheme"
3. Import <user_cert>.p12 into your browser.
4. Access the protected resource via its SSL port. For example:

   https://<ohs_host>:<ohs_port>/index.html
   

   A popup is displayed asking which certificate to use. Select the appropriate certificate and the requested resource is accessed.