In a nutshell, SAML SSO
What is SAML SSO?
SAML, Security Assertion Markup Language, is an XML-based framework used to authorize, authenticate and communicate attribute and privileges of a user. The core concept of SAML is that it passes security information between security domains using assertion. SAML defines set of profile. These profiles are mechanism for asserting and replying parties to exchange information in such way that the replying party can decide whether to trust the asserting party or not.
Background on SAML SSO
SAML is a standard way of conveying identity between Web Services. SAML provide the ability to send information about an authenticated user and does not require a third-party system to ever have access to the user’s credential.
Many organizations are already utilizing SAML to create a better user experience for their customer and employees. However, there are several organizations and governments who have to implement SAML because it can be a difficult and expensive to implement.
What is the benefit of SAML SSO?
SAML provides several benefits to enterprise, organization and governments. One of its greatest benefits is Single Sign-On (SSO). It enables users to securely access multiple applications with a signal set of credential.
How SAML SSO works?
There are three participants that need to be established. They are:
- The User (Client)
- The Identity Provider (IdP)
- The Service Provider (SP)
The Client is attempting to access an application via a Web Service. The Service Provider is the owner of the Web Service. The Identity Provider is the holder of the record of the user’s authentication credentials such as username, password, role etc (may refer as the SAML asserting party). It means that the SAML security token generated and assert the identity of a user in form of security token.
There are two methods of SAML SSO. They are:
- Service Provider Initiated (SP-Initiated)
- Identify Provider Initiated (Id-Initiated)
Id-Initiated SSO is the most common user cases of the two scenarios and it occurs when a user attempts to access the Service Provider directly. Typically, this is the case with mobile devices where a User is already authenticated by accessing their phone. The following is a brief outline how IdP-initiator SSO works.
- The user clicks on a link to a partner Service Provider. Since the user has already been authenticated with identity provider, IdP issues a SAML security token to the User.
- The User’s browser is redirected to the Service Provider
- The Service Provider inspects the inbound SAML security token from the redirect and validates the SAML via the PKI signature check and the SAML contents. If the Service Provider found the security token valid, the user is allowed access and a session cookie is established to enable the continued use of the SSO session for some duration of time without requiring re-authentication.
The second scenario for SAML security token to be issue by Service Provider. This initiation called SP-Initiate. The following describes in high level how the process
- The User attempts to access a service from the Service Provider via URL
- The Service provider redirects the User’s to the Identity Provider for authentication.
- The User provides credential to the Identity Provider. If the user credentials are valid, the IdP create a SAML token and embeds the token along with an HTTP/HTTPS redirect command. The HTTP/HTTPS redirect command send to the User’s browser or mobile device back to the Service Provider to present the SAML security token. This step has no impact on the client and no code is required since it uses standard HTTP/HTTPS redirect mechanisms.
- The Service Provider inspects the inbound SAML security token from the redirect and validates the SAML security token via PKI signature check and the SAML contents. If the Service Provider found the security token valid, the user is allowed access and a session cookie is established to enable the continued use of the SSO session for some duration of time without requiring re-authentication.
The examples above were designed to simplify the two SSO use cases. There were several technical steps were omitted.