Federation Proxy in OAM and IdP

This article explains the concept of Federation Proxy and how 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:

This approach has the advantage of:

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, 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:

Each organization has its own security domain, which means:

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 must establish trust with each remote SP:

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

Description of the illustration Direct_Trust_Model.jpg

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 must 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:

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:

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

Description of the illustration Brokered_Trust_Model.jpg

Federation Proxy in OAM

The goal in a Federation Proxy 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 becomes 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.

OAM supports the Federation Proxy Now for all protocols:

So it would be possible for an SP to do Federation SSO with IdP via SAML 1.1, and IdP becomes 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 OAM/SP and the second IdP, or even that a second Federation SSO operation took place.

In a Federation Proxy Now, IdP can be configured to “forward” the Federation Authentication Method specified in the second Federation SSO to the original SP.

Configuring OAM for Federation Proxy

As discussed in a previously, IdP leverages OAM for user authentication: each time a Federation SSO operation takes place, IdP invokes 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 OAM/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 invokes OAM/SP which triggers a Federation SSO operation with a remote IdP.

So to have IdP do a Federation Proxy Now, instead of having IdP invoking OAM with a local Authentication Scheme, you must have IdP invoked OAM with a FederationScheme. From there:

WLST Command

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

See the article on Authentication in IdP for more information on how to configure OAM for authentication. In this example, configure IdP globally to use Federation SSO as the default authentication mechanism:

  1. Enter the WLST environment by executing: $IAM_ORACLE_HOME/common/bin/wlst.sh.

  2. Connect to the WLS Admin server: connect().

  3. Navigate to the Domain Runtime branch: domainRuntime().

  4. Execute the setIdPDefaultScheme() command: setIdPDefaultScheme("FederationScheme").

  5. Exit the WLST environment: exit().

With this change, FederationScheme is used to authenticate users.

Other Federation Schemes can be used to authenticate the user, with OAM being configured either at the global level (all users from all SPs is authenticated using that Federation Scheme) or at an SP Partner level (all users performing Federation SSO with that specific SP is authenticated using that Federation Scheme). Remember that you can create a Federation Scheme for a specific IdP, either via the OAM 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, OAM/SP will need to determine which IdP to use for the Federation SSO operation:

To set an IdP Partner as the Default SSO IdP:

Proxying Federation Authentication Methods

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

In case of a Federation SSO Proxy Now, that means a FederationScheme is 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 uses a command similar to:

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 IdP to forward the Federation Authentication Methods in a Federation SSO Proxy.

Now, use the useProxiedFedAuthnMethod() command:

  1. Enter the WLST environment by executing: $IAM_ORACLE_HOME/common/bin/wlst.sh.

  2. Connect to the WLS Admin server: connect().

  3. Navigate to the Domain Runtime branch: domainRuntime().

  4. Execute the useProxiedFedAuthnMethod() command: useProxiedFedAuthnMethod(enabled="true/false",authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME").

  5. Exit the WLST environment: exit().

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.