X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • September 19, 2014

DCC HTTP Reverse Proxy with OAM/OIF

Today I will discuss about the Detached Credential Collector (DCC) HTTP Reverse Proxy feature that has been introduced in the 11.1.2.2.0 release.

In a deployment where this feature is enabled, a WebGate SSO Agent:

  • Becomes a reverse HTTP proxy for the OAM and OIF services
  • Interacts with the user over HTTP/HTTPS
  • Routes the incoming HTTP requests for the OAM/OIF servers to the SSO and Federation servers over the secure OAM NAP protocol.
  • Returns to the HTTP client the response sent by OAM/OIF over the NAP protocol

In this mode, all interactions between the users/clients and OAM/OIF will be done via the WebGate DCC HTTP Reverse Proxy: no users will access directly the OAM/OIF servers anymore.

This new DCC HTTP Reverse Proxy capability is different from the previous DCC for HTTP-Basic/FORM based login, with the latter not working for the Federation SSO flows (IdP or SP mode).

Enjoy the reading!

Overview


In this article, I will not include any topologies containing HTTP reverse proxies or load balancer fronting the various OAM components (the OAM server itself or the WebGate agents). I will nonetheless include a use case towards the end indicating how to use DCC HTTP Reverse Proxy in HA deployments, fronted by a load balancer.

Authentication without DCC

The authentication flow without DCC is the most common use case, where the user is redirected from the SSO agents protecting resources in the security domain to the OAM for challenge and authentication.

A typical OAM deployment is made of the following entities:

  • The local Security Domain
  • An OAM runtime server responsible of
    • User authentication
    • Managing SSO Agents
  • Resources
  • SSO Agent deployed on HTTP servers, protecting resources

The following diagram describes such an environment:

In the test flow, I will use the LDAPScheme OOTB as the scheme to protect the resources of the local security domain.

A local authentication flow using the LDAPScheme would consist of the following:

  1. User requests access to a protected resource, defined in OAM to be protected by the LDAPScheme
  2. The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the OAM server for authentication
  3. User accesses the OAM server; the server initiates an authentication flow using the LDAPScheme and displays the login page

Once the user enters its credentials and clicks the login button the following will occur:

  1. The OAM server validates the credentials, creates a session for the user, sets a cookie in the user's browser and redirects the user to the protected resource
  2. The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource

DCC for HTTP-Basic/FORM based login

DCC for HTTP-Basic/FORM based login was introduced in previous releases of OAM 11g, and it provides a way for an administrator to designate a WebGate SSO Agent as the entity which will:
  • Challenge the user for authentication
  • Collect the user's credentials
  • Send them to OAM via the secured OAM NAP protocol for validation
  • Redirect the user to the resource once authentication has been successful
In this mode, the DCC WebGate:
  • Is only used for authentication for
    • HTTP Basic Authentication challenges
    • FORM based authentication
  • Is not used for accessing other OAM services
  • Is only invoked as a credential collector when the scheme protecting the resources is configured to redirect the user to the DCC WebGate
  • Cannot be used in conjunction with OIF as an IdP or SP, or with authentication schemes not based on HTTP Basic Authentication or FORM based authentication

In the test flow, I will use the DCCLDAPScheme that is based on the LDAPScheme OOTB, but with the Challenge URL updated to reference the DCC WebGate. This scheme is used to protect the resources of the local security domain.

A local authentication flow using that custom DCCLDAPScheme would consist of the following:

  1. User requests access to a protected resource, defined in OAM to be protected by the DCCLDAPScheme 
  2. The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate's login page for authentication
  3. User accesses the DCC WebGate's login page and provides credentials
  4. The DCC WebGate interacts directly with the OAM server other the OAM NAP protocol to validate the credentials and to create a session for the user. The DCC WebGate then redirects the user to the protected resource
  5. The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource

DCC HTTP Reverse Proxy 

DCC HTTP Reverse Proxy was introduced in the 11.1.2.2.0 release of OAM/OIF and allows the administrator to configure a WebGate SSO Agent to act as the public endpoint for the OAM and OIF server:
  • The user will be redirected to the DCC WebGate for any authentication operation, without requiring the schemes to be updated to reference the WebGate SSO Agent
  • All OAM services will be accessed via the DCC WebGate
    • Login
    • Logout
  • All OIF services will be accessed via the DCC WebGate
    • Metadata retrieval (/oamfed/idp/metadata or /oamfed/sp/metadata)
    • IdP services
      • IdP Initiated SSO
      • IdP Federation Protocol Endpoints
    • SP services
      • SP Initiated SSO
      • SP Federation Protocol Endpoints
      • Test SP
      • ...
  • The OAM and OIF servers won't be accessed directly anymore
  • The WebGate SSO Agent will receive the incoming HTTP Request, package it and send it to OAM/OIF via the secured OAM NAP protocol; OAM/OIF will process the request and send an HTTP response to the DCC WebGate which will return the HTTP response to the client

Basically, the DCC WebGate becomes the public endpoint for OAM and OIF and acts as an HTTP Reverse Proxy, over the OAM NAP protocol.

In this test, after OAM and the WebGate have been configured for DCC HTTP Reverse Proxy, I will use the LDAPScheme OOTB as the scheme to protect the resources of the local security domain (the scheme won't have been changed)

Note: any authentication scheme with a Challenge URL containing a relative path can be used in this DCC mode, such as the FederationScheme. Also, IdP feature is compatible with that DCC mode

A local authentication flow using the LDAPScheme would consist of the following:

  1. User requests access to a protected resource, defined in OAM to be protected by the LDAPScheme
  2. The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate for authentication
  3. User accesses the DCC WebGate and forwards the request to the OAM server; the server initiates an authentication flow using the LDAPScheme, returns a login page to be displayed to the DCC WebGate, and the DCC WebGate displays the login page to the user

Once the user enters its credentials and clicks the login button the following will occur:

  1. The DCC WebGate sends the HTTP request containing the credentials to the OAM server which validates them, creates a session for the user, creates a cookie and returns an HTTP Response with the cookie and a redirection command to the DCC WebGate; the DCC WebGate sets the cookie in the user's browser and redirects the user to the protected resource
  2. The user requests access to the resource. This time the WebGate SSO Agent will detect that the user is authenticated and will grant access to the resource

Setting Up DCC HTTP Reverse Proxy 


Initial Setup

The steps required to configure an OAM deployment for DCC HTTP Reverse Proxy are divided into:
  • Configure the 11.1.2.2.0+ WebGate SSO Agent for DCC HTTP Reverse Proxy
  • Update the Authentication Policies for the OAM and OIF services
  • Update the OAM configuration to specify the DCC WebGate as the new public endpoint for OAM/OIF

To configure a specific WebGate SSO Agent as a DCC WebGate, perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> SSO Agents
  • Search for the WebGate entry you already registered
  • Click and open the WebGate entry
  • Check the Allow Credentials Collector Operations box
  • In the User Defined Parameter box, add the following line: TunneledUrls=/oam,/oamfed
  • Click Apply

To update the Authentication Policies for the OAM and OIF services, perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Search for the Application Domain related to the DCC WebGate
  • Open the Application Domain 
  • Click on the Resources tab
  • Configure the following resource as Public resources, by marking the resources as Unprotected and setting a public authentication policy and a public authorization policy:
  • /oamfed/.../*
  • /oam/.../*
  • /.../*
  • Apply

To update the OAM configuration to specify the DCC WebGate as the new public endpoint for OAM/OIF

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Configuration -> Access Manager Settings
    • In the OAM Server Host, enter the hostname that will be used to access the DCC WebGate via the browser
    • In the OAM Server Port, enter the port that will be used to access the DCC WebGate via the browser
    • In the OAM Server Protocol, enter the http protocol that will be used to access the DCC WebGate via the browser
    • Once done, those three fields should reference the DCC WebGate HTTP/HTTPS endpoint
  • Apply

Once those three configuration changes are done, OAM and OIF will be configured to use the DCC WebGate as the HTTP Reverse Proxy over the NAP protocol. 

As a test, if Federation has been enabled in the OAM Administration Console -> Configuration -> Available Services section, you can access the OIF metadata via the DCC WebGate URL: http(s)://dcc-webgate-host:dcc-webgate-port/oamfed/idp/metadata, and it should display the SAML 2.0 Metadata for OIF. In my setup, the Metadata showed up without having to restart any services, and the URLs of the Federation services reference the DCC WebGate location, not the OAM/OIF server anymore. 

Note: if the Federation ProviderID needs to be updated, you can do so via the OAM Administration Console -> Configuration -> Federation, and the change will be reflected in the Metadata's entityID attribute

An example of the metadata would be (entityID is derived from the OAM Administration Console -> Configuration -> Federation section):

<md:EntityDescriptor entityID="http://oam.acme.com/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/samlv20"/>
    <md:SingleSignOnService ... Location="http://dcc-webgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

Local Authentication

In my test deployment, I have the following deployed:
  • OAM server running on oam.acme.com on port 14100
  • OHS1 with WebGate1 as an SSO Agent on oam.acme.com on port 23777
    • A resource on that OHS server is /cgi-bin/printenv
    • This resource is protected by a policy using the LDAPScheme
  • OHS2 with WebGate2 acting as the DCC HTTP Reverse Proxy on dcc-webgate.acme.com on port 7777

The LDAPScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC:

Prior to configuring OAM, OIF and the WebGate2 for DCC HTTP Reverse Proxy, requesting access to the /cgi-bin/printenv protected resource on OHS1 was resulting in WebGate1 intercepting the request and redirecting the browser to the OAM server for authentication:

Upon entering the correct credentials, OAM was validating the username/password and redirecting the browser to the protected resource.

After having configured OAM, OIF and the WebGate2 for DCC HTTP Reverse Proxy, requesting access to the /cgi-bin/printenv protected resource on OHS1 now results in WebGate1 intercepting the request and redirecting the browser to the DCC WebGate for authentication which will forward the HTTP request over the NAP protocol to the OAM server which will send back to the DCC WebGate a page to be displayed:

Upon entering the correct credentials, the following occurs:

  • DCC WebGate will package the HTTP Request containing the credentials and send it over NAP to the OAM server
  • OAM server validates the username/password, creates an OAM session, constructs an HTTP Response made of a cookie being set and a 302 redirect referencing the protected resource, packages it and sends it to DCC WebGate
  • DCC WebGate receives the response from the OAM and returns it to the user's browser
  • The user's browser is redirected to the protected resource and granted access

OIF as an SP

This mode slightly differs from the local authentication use case. The only differences are:
  • OIF has been enabled
  • A Federation agreement has been put into place between OIF/SP and a remote IdP, configured in OIF/SP to be the Default SSO Identity Provider
  • Instead of using the LDAPScheme to protect the resource, the FederationScheme is used

No special configuration is necessary to use the FederationScheme with the DCC HTTP Reverse Proxy!

The FederationScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC:

When the protected resource is requested, the following will occur:

  1. User requests access to a protected resource, defined in OAM to be protected by the FederationScheme
  2. The WebGate SSO agent intercepts the HTTP request, determines that the user needs to be authenticated and redirects the user to the DCC WebGate for authentication
  3. User accesses the DCC WebGate, which packages the HTTP requests and send it over NAP to the OAM server; the server determines that the user needs to be challenged via the FederationScheme, and the OIF/SP module is invoked, 
  4. OIF/SP creates a SAML Request and constructs a 302 redirect URL with the SAML message; OAM packages the data and sends the response back to the DCC WebGate which returns the HTTP response to the user's browser
  5. The user's browser is redirected to the IdP with the SAML Request

Once the user enters its credentials at the IdP, the following occurs:

  1. The IdP will create a SAML Assertion and redirect the user's browser with the SAML message to the DCC WebGate (which is the Federation endpoint for OIF, published in the SAML 2.0 Metadata)
  2. The user's browser presents the SAML Assertion to the DCC WebGate, which packages the HTTP requests and send it over NAP to the OAM server, which in turn invokes the OIF/SP module to process the SAML Assertion
  3. OIF/SP validates the SAML Assertion, OAM creates a user session, builds a 302 redirect to the protected resource and sends the response back to the DCC WebGate which returns the HTTP response to the user's browser
  4. The user is redirected to the protected resource; WebGate SSO Agent grants access

OIF as an IdP

In this use case, OIF acts as an Identity Provider and the DCC WebGate is the public endpoint for the OIF/IdP. In this setup:
  • OIF has been enabled
  • A Federation agreement has been put into place between OIF/IdP and a remote SP
  • The OIF/IdP has been configured to use LDAPScheme as the default scheme to authenticate users.
  • The LDAPScheme is the OOTB one and has not been modified, specifically the Challenge URL parameter does not reference WebGate DCC (see the snapshot in the previous section if needed)

No special configuration is necessary to use the OIF/IdP with the DCC HTTP Reverse Proxy!

When a user initiates a Federation SSO from the remote SP, the following will occur:

  1. User starts a Federation SSO operation at the remote SP
  2. The remote SP creates a SAML Request, and redirects the user to the OIF/IdP SAML 2.0 endpoint with the SAML Request: this endpoint is the DCC WebGate HTTP Reverse Proxy, as published in the OIF/IdP SAML 2.0 Metadata 
  3. The User accesses the OIF/IdP public SAML 2.0 endpoint at the DCC WebGate with the SAML Request; the DCC WebGate packages the HTTP Request and the SAML message and forwards it to the OIF/IdP server over the OAM NAP protocol
  4. The OIF/IdP server processes the SAML Request, determines that the user needs to be authenticated via the LDAPScheme, invokes internally OAM for authentication, which in turn return to the DCC WebGate the login page to be displayed; the DCC WebGate decodes the response from OAM sent over NAP, and returns the HTTP response to the user's browser

After the display of the login page, the following will occur:

  1. The user enters its credentials and click the login button; DCC WebGate collects the incoming data, packages it and sends it to the OAM server over NAP
  2. OAM validates the credentials, creates a session for the user, and returns internally the user's identity to OIF/IdP; the Federation server creates a SAML Assertion, and builds a response containing the Assertion, packages it and returns it to the DCC WebGate, which in turn decodes the data, and sends the HTTP Response with the SAML Assertion to the user's browser
  3. The user's browser posts the SAML Response to the SP which successfully validates the Assertion

DCC HTTP Reverse Proxy and HA


In an HA deployment, the steps required to configure the various components (Load balancer, OAM...) still apply when the DCC HTTP Reverse Proxy feature is used. 

Let's take as an example the following deployment (other kinds of HA topologies would use a similar approach):

  • The sample cluster is made of several OAM runtime servers
  • Each server is fronted by a DCC HTTP Reverse Proxy WebGate deployed on an OHS instance
  • A load balancer fronts the various DCC HTTP Reverse Proxy WebGate agents and routes the traffic between them

The topology in this example would look like:

The steps required in this example would be based on:

  • The steps to set up DCC HTTP Reverse Proxy
  • The OAM public endpoint configured in the OAM Administration Console -> Configuration -> Access Manager Settings section would reference the Load Balancer, and not any of the DCC WebGate Agents
  • The Load Balancer would route the /oam and /oamfed requests to the DCC WebGate agents
Cheers,
Damien Carru


Join the discussion

Comments ( 39 )
  • Jon Monday, September 29, 2014

    Hello Damien,

    Thanks for this very handy guide on how to set up DCC in combination with a federation SP.

    Prior to reading it, I was successful in setting up one such environment, but I'm having some issues with the next environment I'm trying. Then I found your blog which suggests that I can use the federation metadata pages for testing, which is a great idea, rather than testing the whole federation setup at once.

    Accessing /oamfed/sp/metadata works like a charm in my first environment, but not in the next. The webgate definitions are identical (including both having TunneledUrls, Allow Credential Collector Operations enabled etc) and the load balancing settings point out the addresses to the DCC webgates.

    When I use an apache/webgate instance against the first OAM it works fine. But when I instead connect the same instance to the other OAM env, Webgate does not understand the /oamfed/sp/metadata requests anymore. It's treated as a non-existent static resource.

    It seems like I'm missing how to make the Webgate aware that it should handle the /oam and /oamfed contexts. Have you seen this before?


  • Damien Monday, September 29, 2014

    Hi Jon,

    There are two things that you should check in your environment:

    1. That /oam and /oamfed are defined as Tunneled URLs in the WebGate User Defined Parameters configuration

    2. That the /oamfed/.../*, /oam/.../* and /.../* resources are created for the Application Domain linked to the WebGate and marked as Unprotected

    If one of the above condition is not met, then the behavior you are describing would be seen.

    Damien


  • guest Thursday, November 6, 2014

    Thanks for the blog, i found it very useful.

    Is the TunneledUrls feature only available in OAM 11.1.2.2 onwards?


  • Damien Thursday, November 6, 2014

    That is correct: the tunneled HTTP proxy requires the 11.1.2.2.0 version or later of WebGate and OAM/OIF.

    Damien


  • guest Tuesday, December 2, 2014

    Great post for extranet users. We are planning to leverage the same footprint for internal as well as external users.

    For intranet based SAML app we want to use Kerberos based SSO. Does this mean that the intranet users will be routed through DCC WebGate which may not be a desired behavior. Do you have any other suggestions.


  • Damien Thursday, December 4, 2014

    Two possible approaches:

    - either you configure Kerberos with the DCC HTTP Reverse Proxy WebGate

    - or you configure a load balancer to be the public OAM endpoint, which will in turn forward the requests to the DCC HTTP Reverse Proxy WebGate for extranet users and to OAM directly for intranet users

    Damien


  • Zach Thursday, January 8, 2015

    Hi, thanks for this. I've set it up, but i can't tell if it's actually using DCC (creating the DCC cookie, etc...)

    My webgate1 is a regular 11g webgate, protecting a resource with LDAPScheme OOTB.

    Webgate2 is DCC enabled, and I went through all the steps. Above.

    The request for the resource gets passed to the webgate2 URL, and I get to my resource. But I just can't tell if it used NAP or not.

    Is there a good way to verify?

    Thanks!

    Zach


  • Damien Tuesday, January 27, 2015

    The best way to verify that OHS2/WebGate2 is using NAP to communicate with the OAM server is to do the following:

    - Go to the /oamfed/idp/metadata URL on OHS2 and ensure you can see the SAML 2.0 Metadata returned by the OAM/OIF server

    - Comment the webgate.conf line in the httpd.conf of OHS2, at the bottom of the file generally: this will not load WebGate anymore on OHS2

    - Restart OHS2

    - Go to the /oamfed/idp/metadata URL on OHS2: if you can see the SAML 2.0 Metadata returned by the OAM/OIF server, then this means there is an HTTP reverse proxy directive in the OHS2 config (forwarding /oamfed, /oam...), otherwise, this means that WebGate is the module tunneling the HTTP requests over NAP to OAM/OIF

    - Uncomment the webgate.conf line in the httpd.conf of OHS2

    - Restart OHS2


  • guest Thursday, March 5, 2015

    Damien,

    First of all let me say this is a great article.

    I have followed it but when I am trying to access OIF from my DCC I am getting the main login /oamfed/idp/initiatesso.... and then it is sending me back to another login /oam/server/...

    Any thoughts as to what might be happening or where I can start looking?

    Thank you Curtis


  • Curtis Tuesday, March 10, 2015

    Damien,

    After setting this up the other resources on my webgate are asking for an additional set of credentials. It Seems like they are not trusting the COOKIE from the IAMSUITEAgent. Could you provide any assistance?

    Thank you

    Curtis


  • Mark Thursday, April 16, 2015

    Hello Damien.

    Could you please confirm if in OAM prior to 11.1.2.2 ( I'm using 11.1.2.1) there is no way to setup reverse proxy for OAM.

    Without reverse proxy we are seeing direct communication between client browser and OAM, which is firewalled and request is timing out.

    Could you please confirm that direct communication between browser and OAM is a programmed behavior.

    Thank you


  • Damien Thursday, April 16, 2015

    When using the DCC HTTP Reverse Proxy feature:

    - designate a WebGate to act as the DCC HTTP Reverse Proxy only. Do not configure that WebGate for the DCC Form Login feature

    - configure that WebGate to tunnel /oam, /oamfed

    - set the necessary policy as explained in the article

    - update the pubic load balancer URL as explained in the article

    - configure the IdP to use for authentication an ECC scheme (such as the LDAPScheme), that is a scheme that is not the DCC Form Login feature.

    The best approach is to use the LDAPScheme for authentication in an IdP flow to ensure everything is set up correctly. From there, use the scheme that you want (except any DCC Form Login schemes).

    Damien


  • Damien Thursday, April 16, 2015

    About the cookie issue, you would need to look at the HTTP headers to ensure that you are being redirected to the correct hostname/port and that no cookies are getting lost.

    Damien


  • Damien Thursday, April 16, 2015

    Hi Mark,

    The DCC HTTP Reverse Proxy feature is only available in 11.1.2.2.0 and later. It is unfortunately not present in the version you are using (11.1.2.1.0)

    Damien


  • guest Thursday, April 16, 2015

    Mark,

    To add to my previous answer, DCC HTTP Reverse Proxy is based on the WebGate communicating directly with the OAM server via the secured OAM NAP protocol.

    Damien


  • Mark Thursday, April 16, 2015

    Hi Damien.

    Thanks for clarification above.

    We are using Kerberos/WNA and planning to add OIF/SAML as a separate OAM/Webgate/OIF.

    Is it possible to setup DCC for Kerberos authentication as reverse proxy. With Kerberos it is Zero Sign on. Currently I observe that at some point after initial exchange with Webgate client sends requests directly to OAM. It represents an issue for us. OAM is behind firewall.

    Hopefully setting up reverse proxy could resolve it.

    Thank you


  • Damien Tuesday, April 28, 2015

    Mark,

    The DCC Form Based authentication seems to be only supported for Form and Basic I think.

    You would need to implement the DCC HTTP Reverse Proxy approach (described here) for this WNA use case I would say.

    Damien


  • guest Thursday, September 24, 2015

    I was trying Google Apps integration with 11gR2PS3.

    1. DCC webgate configured is for credential collection and tunneled for "/oam,/oamdfed".

    2. Also the URL's "/.../*, /oamfed/.../*, /oam/.../*" are added as public resources.

    3. When a federation request is initiated. Login page URL in the browser shows DCC hostname & port but it is the default OAM ECC login page not the DCC login page.

    4. Also SSO doesn't occur with the other DCC authenticated applications.

    Has anyone got it working with 11gR2PS3 or later version.

    Thanks,

    Anumolu.


  • Damien Sunday, October 4, 2015

    Hi Anumolu,

    I would suspect that the OAM/OIF is configured to use the LDAPScheme for authentication. Remember that the DCC HTTP Reverse Proxy with OAM/OIF is different from the DCC login flow: with the DCC HTTP Reverse Proxy with OAM/OIF feature, the WebGate really acts as an HTTP reverse proxy and publishes OAM server functionality via the WebGate endpoint.

    So having the DCC HTTP Reverse Proxy WebGate returning the ECC login page (but via the DCC endpoint) is the expected result.

    Damien


  • guest Thursday, October 8, 2015

    Hi Damien,

    Can I setup WNA for Federation ?

    Before I research in that direction, i wanted to take ur suggestion.

    (shooting in the dark) I believe it could be possible by adding steps similar to Kerberos Plugin in the Federation User Auth Plugin and keeping the Assertion Step as it is...

    but not sure.

    Please suggest.

    Thanks.


  • Damien Tuesday, October 13, 2015

    Hi,

    I would assume it should work, though I did not implement personally that use case.

    Damien


  • Sriram Ravikumar Wednesday, October 14, 2015

    Hi Damien,

    Can I customize the OAM login page, have it hosted on OAM server and then tunnel the custom login URL via DCC webgate?? I have a requirement where my login form has to have a different look and feel for some resources.

    For e.g.:-

    1. Deploy “mylogin.war” (/mylogin/login.jsp) on OAM server

    2. Add “/mylogin” to “TunneledUrls” parameter (DCC webgate profile).

    3. Define a resource “/mylogin/…/*” and protect this using public policies similar

    to “/oam” & “/oamfed”.

    I did try this on OAM 11g R2 PS3 but couldn't get the tunneling to work with my custom login pages.

    Any pointers?

    Sriram.


  • Damien Thursday, October 29, 2015

    Sriram,

    When using the DCC HTTP Reverse Proxy feature, the services hosted by OAM/OIF are registered with a DCC module in the server, to make them available to the DCC HTTP Reverse Proxy WebGate (this includes JSP pages, servlets...)

    Since your application is a web module, it will need to be registered as well. I am not sure this is officially supported today, so you might need to contact Oracle Support and file an Enhancement Request if it is not available.

    Damien


  • Sriram Ravikumar Thursday, October 29, 2015

    Thanks Damien. Currently Oracle doesn't support tunneling to a custom URL. I confirmed this via testing and SR. With Tunneling enabled and a requirement for custom login pages, what's the recommended approach? I tried a few,

    1. Keep DCC tunnel and DCC login webgates separate and have all requests go to DCC login. This did not work as SSO was breaking from federated app to a non-federated app.

    2. Remove DCC tunnel webgate only. Deploy the custom login app on some web app and have a proxy rule on DCC OHS server. This works and I have SSO between federated app to a non-federated app and vice-versa.

    Any others? What's the Oracle recommended practice?

    Sriram.


  • guest Thursday, November 5, 2015

    Damien,

    Nice article. is there another way to make OAM/OIF hide behind DCC by not making DCC as the public endpoint of OAM? We try to avoid internal traffic going to DCC in DMZ.

    In 11gR2PS3 doc, Chapter 23.5.4 Supporting Federation Flows With DCC, Step 4, it says alternatively, you can point to DCC at Authentication Scheme level. I tried it on the federation scheme which protects the resource. But the resource webgate still tunnels to OAM directly.


  • Damien Monday, January 4, 2016

    Chun,

    You can frontend the DCC by a reverse proxy if you want, but the fact is that the DCC WebGate must be the entry point to reach OAM. So you can have: DMZ -> LBR/HTTP Reverse Proxy -> DCC ==> OAM/OIF.

    In this case, you would set the hostname/port/protocol in the OAM Access Settings with the LBR/HTTP Reverse Proxy values.

    Damien


  • Damien Monday, January 4, 2016

    Hi Sriram,

    I would suggest requesting an enhancement to the OAM/OIF product to support the tunneling of custom login pages.

    Damien


  • guest Friday, March 11, 2016

    Good post. I need clarification regarding the article. I'm trying to setup DCC(OIF) for external access(DMZ).

    Does DCC require the OAM server running on the web server(DMZ)?

    Does the webgate1 have to run on the same server as his OAM server?

    Is the protected resource running on the same server as the oam server?

    Is this second OHS2 and Webgate2 on the same web server or a separate web server as the webgate1?

    Does DCC require two DMZ web servers?

    Can you have 2 webgates running on the same server?


  • Damien Friday, March 11, 2016

    Hi,

    Answers to your questions:

    Does DCC require the OAM server running on the web server(DMZ)?

    No

    Does the webgate1 have to run on the same server as his OAM server?

    No

    Is the protected resource running on the same server as the oam server?

    No

    Is this second OHS2 and Webgate2 on the same web server or a separate web server as the webgate1?

    In my test they were separate. You might want to check with your Oracle representative for Access to see if they can be the same.

    Does DCC require two DMZ web servers?

    No

    Can you have 2 webgates running on the same server?

    If using separate ports and separate OHS instances, I do not see why not.

    Regards,

    Damien


  • guest Sunday, March 13, 2016

    Hello Damien

    Thanks for this great post as well following up on the numerous queries from other users. I'd appreciate if you could provide your recommendation on my questions below

    We're trying to implement some OAM OAuth use cases and i notice that putting OAuth services behind the DCC Reverse Proxy does not challenge the user. I'm basically trying some use cases for OAuth from the Oracle A-Team.

    http://www.ateam-oracle.com/implementing-oauth-2-with-oracle-access-manager-oauth-services-part-iv/

    1. What is your recommendation for OAuth services or STS services? Should we include them as tunneled urls?

    2. When using tunneled urls for /oam, /oamfed and webgate is enabled, do we still need mod_wl configurations for /oam or /oamfed?

    Looking forward to your response

    Regards

    Shiva


  • Damien Friday, March 18, 2016

    Hi Shiva,

    I am not sure that the OAuth module supports the DCC HTTP Reverse Proxy feature. You might need to check with PM/Support.

    The same would apply for STS

    Regards,

    Damien


  • guest Saturday, April 2, 2016

    Hello Damian,

    Thanks for writing this. It has really clarified many things for us.

    We have an OAM server fronted by a DCC webgate, which in turn is fronted by F5 LTM (loadbalancer). None of our requests directly go to the OAM server. DCC uses /oamsso-bin/login.pl page for authentication, which we customized for own branding. This setup has been working great for a while now.

    We are now trying to leverage federation capabilities of the OAM server to make it act as IdP so that we can retire our separate OIF server.

    To test, we are using a wordpress as SP. However, whenever a SAML requested is posted to the DCC webgate, we see an error page with following error:

    "System error. Please re-try your action. If you continue to get this error, please contact the Administrator."

    In the oam-diagnostic logs, we see the following entry:

    -------

    [2016-04-01T09:09:35.820-04:00] [oam_server1] [TRACE:16] [] [oracle.oam.binding] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 005BqkNChud3NAbfLHv1DA0001CD0000JW,1:26675] [APP: oam_server#11.1.2.0.0] [URI: /oamfed/idp/samlv20] [SRC_CLASS: oracle.security.am.pbl.transport.http.AMServlet] [SRC_METHOD: getForwardRequestDispatcher] ContextRootProperty: null, ContextValue: /oam, Request Dispatcher: null

    [2016-04-01T09:09:35.820-04:00] [oam_server1] [TRACE:16] [] [oracle.oam.binding] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 005BqkNChud3NAbfLHv1DA0001CD0000JW,1:26675] [APP: oam_server#11.1.2.0.0] [URI: /oamfed/idp/samlv20] [SRC_CLASS: oracle.security.am.pbl.transport.http.AMServlet] [SRC_METHOD: getForwardRequestDispatcher] RETURN null

    [2016-04-01T09:09:35.820-04:00] [oam_server1] [TRACE] [] [oracle.oam.binding] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 005BqkNChud3NAbfLHv1DA0001CD0000JW,1:26675] [APP: oam_server#11.1.2.0.0] [URI: /oamfed/idp/samlv20] [SRC_CLASS: oracle.security.am.pbl.transport.http.AMServlet] [SRC_METHOD: doForward] Invalid settings for forward

    [2016-04-01T09:09:35.820-04:00] [oam_server1] [ERROR] [OAM-00002] [oracle.oam.binding] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 005BqkNChud3NAbfLHv1DA0001CD0000JW,1:26675] [APP: oam_server#11.1.2.0.0] [URI: /oamfed/idp/samlv20] Error occurred while handling the request.[[

    oracle.security.am.common.utilities.exception.AmRuntimeException: Invalid settings for forward

    at oracle.security.am.pbl.transport.http.AMServlet.doForward(AMServlet.java:662)

    at oracle.security.am.pbl.transport.http.AMServlet.handleResponse(AMServlet.java:518)

    at oracle.security.am.pbl.transport.http.AMServlet.handleRequest(AMServlet.java:203)

    at oracle.security.am.pbl.transport.http.AMServlet.doPost(AMServlet.java:157)

    at oracle.security.am.pbl.transport.http.AMServlet.doGet(AMServlet.java:890)

    ---------

    We also created a LoopbackIDP and loopbackSP to test things. However, the error remains.

    We have an SR open. However, thought you may have some insight on this. Would highly appreciate your response.

    Thanks

    Manish


  • guest Thursday, July 14, 2016

    Hello Damien,

    Thanks for explaining DCC HTTP Reverse proxy article. While going through this article you mentioned: - designate a WebGate to act as the DCC HTTP Reverse Proxy only. Do not configure that WebGate for the DCC Form Login feature. I am not clear if I need to have 2 seperate DCC or a single DCC can be used.

    Currently in our environment we have DCC setup using DCCauthenticationscheme that is using out of the box login.pl and all the protected resource are redirected to DCC for authentication. If I am using Federation in OAM 11.1.2.3 do I need to have 2 DCC setup one for Federation to act as public end point and one for Form based login?

    Can I use a one DCC HTTP reverse proxy to achieve both?

    Regards

    Sidd


  • Ramanathan Tuesday, July 26, 2016

    Nice read. I have a situation. We have an ECC webgate based architecture providing web based single sign on. Can we have an ECC webgate based architecture to offer OAM/OID services as well to ensure no conflicts here?

    Ram


  • Damien Wednesday, November 30, 2016

    Hi,

    The DCC Reverse Proxy acts as an HTTP Reverse Proxy for the OAM server. As such, one would expect the login pages to be hosted by the OAM server, not the /oamsso-bin/login.pl which runs on the WebGate. I would suggest you to use a login page hosted by OAM server.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Sidd,

    A single WebGate can be used as the DCC Reverse Proxy: in this case, this WebGate acts as an HTTP Reverse Proxy over the secured OAM protocol with the OAM server. Typically, in that scenario, the login.pl should not be used, but instead the login pages hosted by the OAM server would be used.

    Damien

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Ram,

    I am not sure. You would need to reach out to Oracle Support for this question.

    Damien


  • Spirito Saturday, January 28, 2017

    Just for feedback, the Tunneled Urls didn't work for me until I added this in User Defined Parameters: enableTunnelingForCustomeContext = true.

    Regards!

    Spirito


  • Damien Monday, February 6, 2017

    Hi Spirito,

    I was not aware of this property: perhaps it was recently introduced.

    Thank you for sharing your solution!

    Regards,

    Damien


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.