The customer request

Recently in my day job, we received a request from one of our enterprise customers to integrate Single Sign-On (SSO) into our product. The customer was already utilizing Microsoft Azure Active Directory (Entra ID) as their identity provider. For those new to integrating SAML-based SSO, the process can be quite complex. As fate would have it - I used to work at Microsoft where I worked specifically on Azure AD in the Identity team! In this article, I provide an overview of SSO and share recommendations for startups considering its integration.

What problem does SSO solve?

Single Sign-On (SSO) is a user authentication process that allows individuals to access multiple applications with one set of login credentials. A good analogy is your gym membership card. With one swipe you can access the gym, pool and other services without having to swipe again for each amenity. Tying this back to our customer - each of their employees has a single username password / mfa combination with Microsoft. Without an SSO integration, they would need separate login credentials and MFA for Truewind and any other service the accounting firm provides. This makes it extremely challenging to manage access for the 20+ apps and services required by the hundreds of employees who join and leave the company. With SSO they can provision a single set of credentials and a new employee has access to everything, and they can similarly revoke a single set of credentials when an employee leaves the company.

Components of SSO

To understand how SSO works let’s first get an overview of the architectural components.

1. Identity Provider (IdP): Authenticates user credentials and serves as the central authority for identity (e.g., Microsoft Azure Active Directory / Github / Facebook), facilitating secure access management.
2. Authentication Token: Generated by the IdP post-authentication, this time-bound token securely conveys user identity and access rights, ensuring that only authorized users gain access to protected applications.
3. Service Provider (SP): The application or service being accessed that relies on the IdP for user authentication, validating the token to grant seamless access without additional logins. This is also known as the protected or integrated application or user experience that can be accessed with the single sign on.
4. User / Identity: The user or credentials trying to access the underlying application or service.

The SSO login procedure

This is how the above components interact to complete the SSO login flow:

1. The user attempts to access a protected application (Service Provider or SP).
2. The application redirects the user to the Identity Provider (IdP) for authentication.
3. The IdP prompts the user to enter their credentials and verifies them.
4. Upon successful authentication, the IdP generates a secure, time-bound authentication token.
5. This token, containing the user's identity and access rights, is sent back to the user directly.
6. User sends the token to SP.
7. The SP validates the token with IDP and grants the user access to the application without requiring additional logins, ensuring a seamless and secure login experience.

The integration

Follow the beaten path

The initial integration is straightforward. You can follow the official guide here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on

1. Register the Application: In Azure AD, register the application you want to integrate with SAML SSO.
2. Configure SAML Settings: Set up the basic SAML configuration in Azure AD, including the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL).
3. Download SAML Metadata: Obtain the SAML metadata file or URL from Azure AD for your application.
4. Set Up the Application: In the application, configure the SAML settings using the metadata from Azure AD, specifying the IdP details.
5. Assign Users: Assign the appropriate users or groups to the application in Azure AD.
6. Test the Integration: Verify that users can authenticate through Azure AD and access the application using SAML SSO.

The Real challenge

The challenge is determining how your existing password users will transition to the SSO flow. For many enterprise customers, the sales / onboarding process usually involves:

1. Creation of Password Accounts: Many accounts are created during the trial period.
2. Post-Contract SSO Integration: Once a contract is signed, SSO is integrated. Now, you need to figure out how to migrate these existing password accounts and their data to the identity provider flow, ensuring a seamless transition for all users.

Why it is difficult

The complexity of transitioning to SSO largely depends on your existing authentication model. Most initial identity setups tie the login method, such as a password, directly to the user identity. This often results in data models keyed off the login identifier. To update your model effectively, you must decouple the login method from the underlying identity, typically represented by an email address.

Next, you need to disable password logins and enforce that all sign-ins and sign-ups within the domain authenticate exclusively through SSO. Integrating all domain-joined identities to automatically join the organization and copying existing permission models adds another layer of complexity. This ensures the transition maintains the same access controls and user permissions, making the entire process challenging but essential for a smooth SSO integration.

Concrete example

Here's a common schema design for a single authentication method system that most people would typically create.

The data model needs to be able to separate the user entity from the auth method as well as define the active authentication method in the enterprise case. Here's how the schema looks after such a change.

Matt’s recommendations

Should you integrate SSO into your product? It depends on your customer base. For enterprise customers, integrating with an Identity Provider can enhance user experience and help attract enterprise clients. Initially, passwords may suffice to test your value proposition but as you try to close larger clients you'll eventually hit the hard requirement for SSO support.

My recommendation is to integrate SSO based on customer demand, such as signing a major client or increasing revenue. Early on, prioritize testing your core value proposition over SSO implementation. If you are planning future SSO integration, decouple authentication methods from user identities to ensure a smooth transition.

If you want to see some more of my written content outside of this blog check out my recent articles .