Single Sign-On(SSO) -SAML Authentication Explained
What is Single sign-on?
Single sign-on (SSO) is a property of identity and access management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once with just one set of credentials (username and password).
This saves the user from remembering multiple usernames and passwords, while still providing strong authentication. And, once they have logged in, an end-user can access other connected web apps without logging in again, until their authenticated session expires.
How does SSO work?
Authentication with SSO relies on a trust relationship between domains (websites). With single sign-on, this is what happens when you try to log in to an app or website:
- The website first checks to see whether you’ve already been authenticated by the SSO solution, in which case it gives you access to the site.
- If you haven’t, it sends you to the SSO solution to log in.
- You enter the single username/password that you use for corporate access.
- The SSO solution requests authentication from the identity provider or authentication system that your company uses. It verifies your identity and notifies the SSO solution.
- The SSO solution passes authentication data to the website and returns you to that site.
- After login, the site passes authentication verification data with you as you move through the site to verify that you are authenticated each time you go to a new page.
In SSO, authentication verification data takes the form of tokens.
SSO Strategy
SAML is an XML-based open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.
What is SAML?
Security Assertion Markup Language (SAML) is a very powerful and flexible standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
- No need to type in credentials
- No need to remember and renew passwords
- No weak passwords
Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users into other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML.
WHY USE SAML?
SAML is the gold standard for single sign-on for cloud apps. It eliminates all passwords and instead uses digital signatures to establish trust between the identity provider and the cloud app. Using SAML, users can seamlessly access multiple applications, allowing them to conduct business faster and more efficiently.
SSO also helps organizations to login employes to all the organization related applications with just a single username and password which can we associated with their system and the Active directory they are already managing and with SAML we can do Authorization and Authentication both.
For Example, we Integrated our BrightLab app with Organization’s Azure AD to login to the application with the same company’s email and they don’t have to log in if already logged in to any of the application associated with same AD ie. their Outlook any other App.
User requests access Flow
The website redirects the user to the SSO website to log in. The user logs in with a single username and password.
The SSO website verifies the user’s identity with an identity provider, such as Active Directory.
User is granted access and then requests access to a new site
When the user tries to access a different website, the new website checks with the SSO solution. Since the user has been authenticated, it verifies the user’s identity to the new website without requiring an additional login.
A Service Provider (SP) is the entity providing the service, typically in the form of an application.
An Identity Provider (IdP) is the entity providing the identities, including the ability to authenticate a user. The Identity Provider typically also contains the user profile: additional information about the user such as first name, last name, job code, phone number, address, and so on. Depending on the application, some service providers may require a very simple profile (username, email), while others may require a richer set of user data (job code, department, address, location, manager, and so on).
A SAML Request, also known as an authentication request, is generated by the Service Provider to “request” an authentication.
A SAML Response is generated by the Identity Provider. It contains the actual assertion of the authenticated user. In addition, a SAML Response may contain additional information, such as user profile information and group/role information, depending on what the Service Provider can support.
A Service Provider Initiated (SP-initiated) sign-in describes the SAML sign-in flow when initiated by the Service Provider. This is typically triggered when the end-user tries to access a resource or sign in directly on the Service Provider side, such as when the browser tries to access a protected resource on the Service Provider side.
An Identity Provider Initiated (IdP-initiated) sign-in describes the SAML sign-in flow initiated by the Identity Provider. Instead of the SAML flow being triggered by redirection from the Service Provider, in this flow, the Identity Provider initiates a SAML Response that is redirected to the Service Provider to assert the user’s identity.
SAML SSO Flow
The diagram below illustrates the single sign-on flow for service provider-initiated SSO, i.e. when an application triggers SSO.
Identity provider-initiated SSO is similar and consists of only the bottom half of the flow.
How SAML Works
SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.
Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:
- The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
- The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
- The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
- The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
- The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
- The identity of the user is established, and the user is provided with app access.
Implement SSO with Node.js
Implementation of SSO with SAML in Node.js using Passport.js middleware.
