Organizations utilizing multiple identity providers may find it challenging to implement a unified single-sign-on experience. This article showcases how F5 BIG-IP Access Policy Manager (APM) can address the problem.

Problem Statement

Organizations may find themselves in situations where they are running multiple identity providers (IdP) in the environment, which could occur due to reasons such as

1. Mergers and acquisitions,
2. Migrating to a new IdP, or
3. Business units operating in their own silos.

In one such encounter, a F5 customer has two IdPs managing identities for two groups of users, each with its own email domains (scenario 3 above). Challenge arose when they wanted to enable SAML Single Sign-On (SSO) for their business applications, where the logon process needs to be able to direct users to the right IdPs to complete the logon process and access the applications.

Implementation

With BIG-IP Access Policy Manager (APM) being a well-established solution as an SAML Service Provider use case, we can address the challenge above by extending existing SAML SP access policies. The business applications are hosted behind BIG-IP Virtual Servers, with APM/access policies attached to them. The policies look a little something like below:

APM policy to perform IdP routing

The idea is simple - leverage the programmability of BIG-IP data plane to capture the differentiating users attribute and use it to route users to the corresponding IdPs.

In this case, as each user group has their own unique domains in their email address/username, we first present a logon page from the APM to capture the information from the user:

APM Logon page to get user email address/domain

The email address/username, stored under the APM session variable session.logon.last.username, is then passed on to the next action item, which evaluates custom expressions to categorize users by the email domain, represented by the various branches out from this action.

Branch rules to route user logon flows to various IdPs based on email domains

Based on the domain in the provided email address, the SAML Auth actions redirect users to the different IdPs as seen in the table below.

For consistency, each business application is registered on both IdPs with the same entity IDs and callback URLs.

Email address/Username	someone@f5.com	someone@gmail.com
Domain	f5.com	gmail.com
IdP	Microsoft Entra ID	Auth0
Logon page presented

Once the user finishes the logon process through the IdP, they are redirected back to BIG-IP, which allows the user through to the business application, completing the SSO flow.

You will find that when redirected to the IdP logon page, users have to re-enter their email address, despite having already done that on the APM logon page. 

To avoid this, some IdPs such as Microsoft Entra ID supports login hints, where the sign in name field can be pre-populated with the email address provided in the initial logon page from APM. 

Implementation will be IdP-dependent. A neat example for configuring APM to support login hints for Microsoft Entra ID can be found in this CodeShare article.

Conclusion

With the above implementation, APM is able to remove unnecessary business logic from all the applications to handle various logon flows to multiple IdPs, securing applications via SSO without introducing additional user friction.