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:
This approach has the advantage of:
Enjoy the reading!
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:
Each organization has its own security domain, which means:
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:
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.
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:
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:
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:
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.
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:
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:
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:
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.
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:
To set an IdP Partner as the Default SSO IdP:
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:
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:
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.