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

Deploying seperate DCC and resource Webgate is considered as the best practise implementation. 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 11.1.2 DCC-enabled WebGate for authentication

  • Resource WebGate that redirects to the 11.1.2 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


Configuring combined DCC and Resource WebGate can result in failure when using virtual hosting or DCC tunneling.

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 follows
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 11g 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.


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

Figure 23-3 Combined DCC and WebGate Configuration

Description of Figure 23-3 follows
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-23).

  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.