I am currently working on a project involving multiple service providers, each with a distinct domain, such as “domain1.com”, “domain2.com”, and so on. Each domain has its own custom login URL, for example, “login.domain1.com”, “login.domain2.com”, etc. Our objective is to implement Single Sign-On (SSO) across these various domains, but we are facing challenges.

In our current setup, service providers redirect users to the identity provider, where a cookie indicating an active session is set. However, this cookie is bound to the identity provider’s domain, preventing it from being shared across different domains. Consequently, we are unable to achieve SSO functionality between these domains.

We aren’t using a third-party federation solution. We are currently utilizing Azure AD B2C, backed by Microsoft Entra ID, to deliver a custom login experience for our users. Our implementation involves multiple custom login domains, all pointing to the same Azure AD B2C tenant.

We aim to achieve the following scenario:

Initial Login: Users access Azure AD B2C through a custom domain URL:

https://login.domain1.com/domain1.onmicrosoft.com/B2C_1A_signup_signin_saml/generic/login?EntityId=https://anotherwebappdomain.com/integration/splogin&ui_locales=en-GB
Once authenticated, an active session is established.

Seamless SSO Experience: If the user subsequently navigates to another custom login domain URL:

https://login.domain2.com/tenantname.onmicrosoft.com/B2C_1A_signup_signin_saml/generic/login?EntityId=https://anotherwebappdomain.com/integration/splogin&ui_locales=en-GB
The system should automatically recognize the existing session and log the user in without requiring them to re-authenticate.

Our goal is to ensure a seamless Single Sign-On (SSO) experience across these different custom login domains while leveraging the same Azure AD B2C tenant.

We initially attempted to use a unified login domain (login.domain.com) for all applications pointing to our Azure AD B2C identity provider, which successfully provided the necessary SSO functionality. However, our client requires distinct login domains for each application.

In response to this requirement, we have implemented custom login domains for each application. Despite exploring various solutions, including session management within our custom policies and the use of hidden iframes to reach a single domain, we have yet to achieve the desired SSO functionality.

Best regards,

Simon Vandeputte