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:
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.
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:
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
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.
Note:
Encryption occurs only from an 11g resource WebGate to the DCC. The channel is not encrypted for communication between 10g resource WebGate and 11g DCC; this is in clear text.
Figure 23-3 Combined DCC and WebGate Configuration
Process overview: Authentication with the combined DCC and Resource Webgate
The user requests access to a resource which initiates the authentication process.
The DCC redirects through the front channel to the login page.
The login page is returned to the user.
User enters credentials, which are posted to the action URL (a user-defined parameter in an authentication scheme, Table 22-23).
Authentication occurs using the back channel (OAP) and OAM Proxy.
The Authentication Plug-in is activated.
The Plug-in requests redirect to a URL to collect additional credentials.
The Plug-in request is returned to the DCC.
The DCC redirects to the URL and expects specified credentials.
The Browser follows the redirect.
Credentials are posted to the Action URL.