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

  • October 6, 2014

Federation Proxy in OIF / IdP

In this article, I will explain the concept of Federation Proxy and how OIF/IdP can easily be configured to become an SP and delegate authentication to another remote IdP instead of authenticating the user locally.

Federation Proxy is typically used when a Federation hub acts as:

  • An IdP for SP Partners, where the IdP aggregates Federation trust between those SPs and itself
  • An SP with remote IdP Partners

This approach has the advantage of:

  • Reducing trust management overhead:
    • Each new IdP Partner added to the Federation hub will be automatically available to all the SP partners integrated with the Federation hub
    • Each new SP Partner added to the Federation hub won't need to be defined at the IdP Partners    
  • Providing a layered Federation trust model, where the Federation hub hides the Federation deployment to the IdP Partners

Enjoy the reading!

Direct Trust Model

In this model, the various Federation servers trust each other directly and there are no intermediate entities acting as proxy.

This model has the advantage of reducing the complexity of the Federation flows, because only two servers are involved with the SSO operation, but sometimes it has the drawback to create a huge management overhead that partners might not agree to.

Let's take an example of a global company called ACME Corp (how original!), which has offices in the whole world. The structure of the company is made of three top organizations representing a different region of the globe, and each organization is in charge of its security domain:

  • North & South American
  • European
  • Asia-Africa-Pacific

Each organization has its own security domain, which means:

  • A set of resources
  • An SSO server
  • A Federation server

The entities of one organization are independent of the ones from another organization. As such, being authenticated in one domain will not grant you access to resources of another domain until authentication has been performed in that other domain.

Now, let's say that ACME Corp wants to have Federation agreement in place with some Service Providers, some of which being suppliers, others being services purchased by ACME Corp, such as a Conference Call service, as well as a Webex service.

In order to establish Federation between the various ACME Corp organizations and the SPs, each organization's Federation server will need to establish trust with each remote SP:

  • The number of trust establishment will be high
  • The SP Partners might refuse to this kind of trust establishment, given the high number of Federation agreements involved for a single customer

This diagram represents all the agreements that would need to be put in place:

This approach is typically avoided, because it publishes to the partner the internal complexity of ACME Corp's infrastructure.

Federation SSO and SAML were defined to allow two distinct security domains to perform cross domain SSO in a way that one partner would not need to know about the security implementation and deployment of the other partner. In this case, it becomes obvious that this promise is broken and that the complexity of ACME Corp's security choices is impacting the SP partners.

Brokered Trust Model

In this model, there is the concept of Federation Proxy where some entities will be used to act as proxies/SPs to perform Federation SSO operations on behalf of other SPs.

If we take our example of ACME Corp again, the correct approach to implement Federation SSO with other SP Partners is via a Brokered Trust model or Federation Proxy, where:

  • A new server will be installed in ACME Corp acting as a Federation hub
  • The Federation Hub will act as a Service Provider to the internal IdPs of ACME Corp
  • The Federation Hub will act as an IdP to the external SPs (suppliers, conference call and webex)
  • During a Federation SSO operation, instead of challenging the user directly, the hub will act as an SP and trigger a Federation SSO operation with a remote internal IdP

This approach is more in line with the Federation/SAML philosophy, where the external partners are unaware of the security infrastructure and components of ACME Corp, and only interact with a single IdP.

This solution also solves the high management overhead where the number of agreements was particularly high and was making any updates to the agreement a lengthy process. With this approach:

  • Federation agreements are between the hub and internal IdPs, and between the hub and external SPs
  • Adding an internal IdP will be invisible to the external SPs
  • Adding an external SP will be invisible to the internal IdPs
  • Updating the Federation agreement (for example for key rollover) will be a one-time operation as opposed to be repeated multiple times

This diagram represents the Federation agreements required in a Brokered Trust (or Federation Proxy) model:

Federation Proxy in OIF

The goal in a Federation Proxy flow is to turn the IdP into an SP so that upon receiving an SSO request from a first remote SP, instead of challenging the user locally, the IdP will become an SP and trigger a new Federation SSO operation with a second remote IdP.

Upon the successful completion of the second Federation SSO operation, the proxying IdP will have identified the user and will be able to create an SSO response for the original SP.

OIF supports the Federation Proxy flow for all protocols:

  • SAML 2.0, SAML 1.1 and OpenID 2.0
  • Protocol between original SP and OIF/IdP is the same as the one used between OIF/SP and the second remote IdP
  • Protocol between original SP and OIF/IdP is different then the one used between OIF/SP and the second remote IdP

So it would be possible for an SP to do Federation SSO with OIF/IdP via SAML 1.1, and OIF/IdP would become an SP and do Federation SSO with a second remote IdP via SAML 2.0. The original SP would not need to know the protocol used between OIF/SP and the second IdP, or even that a second Federation SSO operation took place.

In a Federation Proxy flow, OIF/IdP can be configured to "forward" the Federation Authentication Method specified in the second Federation SSO to the original SP.

Configuring OIF for Federation Proxy

As discussed in a previous article, OIF/IdP leverages OAM for user authentication: each time a Federation SSO operation takes place, OIF/IdP will invoke OAM by specifying an Authentication Scheme, to ensure that the user is adequately authenticated, and challenge him/her if necessary.

As you know, OAM defines specific schemes which are tied to OIF/SP: if a non authenticated user requests access to a resource protected by a FederationScheme (or scheme using an Authentication Module similar to the FederationPlugin), OAM will invoke OIF/SP which will trigger a Federation SSO operation with a remote IdP.

So to have OIF/IdP do a Federation Proxy flow, instead of having OIF/IdP invoking OAM with a local Authentication Scheme, you will need to have OIF/IdP invoke OAM with a FederationScheme. From there:

  • OAM will invoke OIF/SP and that will trigger a new Federation SSO flow with a second remote IdP
  • The second remote IdP will authenticate the user if needed, issue an SSO response
  • OIF/SP will validate the SSO response, create an OAM session
  • OAM will redirect the user to OIF/IdP
  • OIF/IdP will create an SSO response and redirect the user to the original SP with that response

WLST Command

To configure OIF/IdP to use Federation SSO to authenticate a user instead of a local authentication mechanism, execute the one of the following commands:

  • setIdPDefaultScheme() to set the global default scheme to be a Federation Scheme
  • setSPPartnerProfileDefaultScheme() to set the default scheme on an SP Partner Profile
  • setSPPartnerDefaultScheme() to set the default scheme on an SP Partner

See the article on Authentication in OIF/IdP for more information on how to configure OIF for authentication.

In my example, I will configure OIF/IdP globally to use Federation SSO as the default authentication mechanism:

  • Enter the WLST environment by executing:
  • Connect to the WLS Admin server:
  • Navigate to the Domain Runtime branch:
  • Execute the setIdPDefaultScheme() command:
  • Exit the WLST environment:

With this change, FederationScheme will be used to authenticate users.

Other Federation Schemes can be used to authenticate the user, with OIF being configured either at the global level (all users from all SPs will be authenticated using that Federation Scheme) or at an SP Partner level (all users performing Federation SSO with that specific SP will be authenticated using that Federation Scheme). Remember that you can create a Federation Scheme for a specific IdP, either via the OIF WLST createAuthnSchemeAndModule command, or via the Edit IdP Partner section in the OAM Administration Console.

Determining the Second IdP to be used

When a Federation Scheme is used for authentication in OAM, OIF/SP will need to determine which IdP to use for the Federation SSO operation:

  • If the scheme was one that was created from an IdP Partner entry, then it will indicate to OIF/SP to perform Federation SSO with that IdP
  • If the scheme is FederationScheme, then OIF/SP will first evaluate if it is configured to use an IdP Discovery Service
    • If it is configured for an IdP Discovery Service, OIF/SP will redirect the user to that service to select an IdP
    • Otherwise, OIF/SP will use the Default SSO IdP

To set an IdP Partner as the Default SSO IdP:

  • Either go to the IdP Partner in the OAM Administration Console and check the "Default Identity Provider Partner" box
  • Or use the OIF WLST setDefaultSSOIdPPartner() command by specifying the IdP Partner name

Proxying Federation Authentication Methods

As I explained in a previous article, when OIF/IdP constructs an Assertion, it will map the local OAM scheme used to authenticate the user to a Federation Authentication Method.

In case of a Federation SSO Proxy flow, that would mean that a FederationScheme would be mapped to a Federation Authentication Method. For example, if the scheme needs to be mapped to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport for SAML 2.0, the administrator would use a command similar to:

  • To create the mapping at an SP Partner Profile level:
    addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")
  • To create the mapping at an SP Partner level:
    addSPPartnerAuthnMethod("AcmeSP", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")

In some cases, it might be preferable to forward the Federation Authentication Method received from the second IdP instead of mapping locally the Federation Scheme to a Federation Authentication Method.

To configure OIF/IdP to forward the Federation Authentication Methods in a Federation SSO Proxy flow, use the useProxiedFedAuthnMethod() command:

  • Enter the WLST environment by executing:
  • Connect to the WLS Admin server:
  • Navigate to the Domain Runtime branch:
  • Execute the useProxiedFedAuthnMethod() command:
    useProxiedFedAuthnMethod(enabled="true/false", authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME")
    • The enabled parameter indicates whether or not OIF/IdP should be configured to forward the Federation Authentication Methods in a Federation SSO Proxy flow
    • The authnSchemeToAdd parameter indicates which OAM Authentication Scheme is a Federation Scheme: this will allow OIF/IdP to determine whether or not to use the cached Federation Authentication Method based on the authentication scheme of the user's session
    • The authnSchemeToRemove parameter removes an OAM Authentication Scheme from the list of schemes marked as Federation Schemes for which OIF/IdP should use the proxied Federation Authentication Method
    • An example would be:
      useProxiedFedAuthnMethod(enabled="true", authnSchemeToAdd="FederationScheme")
  • Exit the WLST environment:

In the next article, I will explain in details how OIF/SP can be configured to determine the IdP to be used for a Federation SSO operation.
Damien Carru

Join the discussion

Comments ( 10 )
  • Divya Wednesday, May 27, 2015

    Hi damien

    Great article , can this entire set up be done within OAM 11gr2 PS2 without stand alone OIF . OAM federation services acting both as SP for remote IDP partner and as IDP for its federated SP partners.

  • Damien Wednesday, May 27, 2015

    Hi Divya,

    This article covers OAM/OIF and later versions and does not rely on OIF 11.1.1.*.0.


  • Divya Thursday, May 28, 2015

    Hi Damien


    Basically , I'm doing feasibility analysis to set up OAM 11gr2ps2 to meet all federation requirements ,

    So, when you specify OAM/OIf , does it refer to standalone OAM and OIf servers and integration.

    Or, OAM integrated federation services can fully function like Standalone OIF services.? Thanks a ton for the help



  • Divya Friday, May 29, 2015

    I have worked with OIF 11g and OAM 11g. Hence , I need to know if by installing OAM 11gr2PS2 entire suite , I will be able to configure all federation services like I can do in Stand alone OIF server.

    Thanks !!!

  • Damien Monday, July 27, 2015

    Hi Divya,

    This article refers to OAM/OIF There is only one set of products with that version.

    You might be confusing with OAM/OIF 11.1.1.*

    Hope this helps,


  • cchiappe Tuesday, October 13, 2015

    Hi Damien, I have a question for you. I can see a couple of scenarios where only Service Providers are involved in an interaction with the Identity Provider infrastructure (in my case the IdP is OAM). But what would happen if there's the N Service Providers and on the other hand one application protected by a traditional webgate?. Is there Single Sign-on in this scenario when the user authenticates via the webgate and then tries to navigate to a SP resource?.

    Thanks in advance,


  • Damien Tuesday, October 13, 2015

    Hi Carlos,

    In this case, the WebGate (and the protected resource) would reside in the ACME Corp domain and would be integrated with the OAM server which acts as a proxy (the Federation Hub).

    In that case, you could protect that local resource with the Federation Scheme, that would start Federation SSO with one of the organizational IdPs.

    Remember, when the IdP needs to authenticate a user, it will use an OAM scheme. Similarly, when the WebGate needs to authenticate a user, it will use an OAM scheme.

    So in the end, both IdP and local WebGate need to be configured to use a Federation Scheme to authenticate the user, that will result in a Federation SSO operation.


  • cchiappe Thursday, October 15, 2015

    Hi Damien. I have a couple of questions given the answer you gave me. We have 2 SP applications: CRM and Self Service. We have 1 IdP: OAM. We need to provide SSO for the 2 SP, so the user is NOT prompted for re-authentication when passing from CRM to Self Service or vice versa.

    1) ¿Is this possible?

    2) If so, ¿Which approach should I follow?



  • Sg Wednesday, May 24, 2017
    Hi Damien,

    Quick question; in order for this to work would the user need to exist in the SP, Fed Hub and IDP.

  • Damien Wednesday, May 31, 2017
    Hi Sg,

    It depends on the Federation server. In this case where OAM/OIF is used, the user will need to exist in the LDAP directory for this flow to work, as a user session in OAM only exists if a user record exists in LDAP.

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