SAML 2.0
Basics
Security Assertion Markup Language (SAML) is an industry standard for enabling users into client applications based on sessions. It allows Identity Providers (IdP) to transmit authorization credentials to a Service Providers (SP). Meaning, it is possible to use a set of credentials of a particular user and log into different client applications. This Single Sign-On (SSO) standard used for login purposes has considerable advantages than users logging in with a username and password i.e., there is no need for typing in credentials, there is no need for renewing and remembering passwords, and there is no more weak passwords.
Most of the organizations know the identity of their users because in one or the other flows the users are logged into Active Directories (AD) domain. This information is more than enough to enable users to log into other services and applications, such as web applications. The most classic way for enabling this process is by using SAML protocol.
Why use SAML for my application?
Following are the advantages of using SAML based authentication process:
Standard Protocol
SAML is an industry specific standard that enables seamless interoperability between any systems. It eliminates the most generic problems correlated with vendors and architectures which are platform specific.
Enhanced User Experience
Users will be able to access multiple SPs by logging in once without the need for an additional authentication flows. This allows for faster and better user experience at each SP. By implementing SAML, it eliminates an password related issues such as recovery and reset.
Enhanced Security
Security is a one of the key aspect for any software development processes, and at enterprise level application development, it becomes trivial. SAML enables single point of authentication, which takes place at a secure IdP platform. Then, SAML transmits identity to SPs. This authentication process ensures that the credentials do not leave the restricted boundaries (such as firewall rules).
Loose Coupling of Directories
SAML does not require any user information to be maintained and synchronized between ADs.
Decreased Cost for Service Providers
With SAML, you do not need to maintain account information across services. Here, the IdP bears the responsibility.
How it works?
SAML SSO works by transmitting user’s identity from one place (i.e., IdP) to another (i.e., SP). This is performed through an exchange of XML-file which is digitally signed.
For example: Consider an end-user who has logged into a system which is an IdP. The end-user intends to log into an application, such as a support application (i.e., SP). The following steps takes place in sequence:
- The end-user connects to an application via a weblink placed on an intranet page or a bookmark or something similar.
- The application identifies the end-user’s Origin (i.e., application's subdomain, IP address, etc.) and then redirects the end-user back to IdP, requesting for authentication.
- The end-user either has an already active browser session with the IdP or establishes a new session by logging into the IdP.
- The IdP builds authentication response in an XML-file format consisting of end-user’s information (such as name or e-mail address), digitally signs with an X.509 certificate and transmits this information to SP.
- The SP which already knows about the IdP and also having the fingerprint of the certificate, captures the response of authentication flow and verifies it with the fingerprint.
- The identity of end-user will be established and the end-user will be enabled access to the application.
Flows
SAML typically includes a federation SSO deployment consisting of following entities:
- Security domain for an IdP server, where an end-user has an account. Additionally, authentication flow is performed under this domain.
- Security domain for SP server along with:
- SP federation server.
- SSO server (usually, SSO Server and SP federation server are the same)
- SSO agent (usually, web application agents) integrated with SSO server. An agents is responsible to ensure that an end-user is authenticated and authorized appropriately to access the resource.
- Web application.
Federation SSO deployment is executed or operated in one of the following described flows:
IdP initiated flow
In this flow, the federation SSO deployment is initiated from an IdP server by creating a SSO response and then redirecting the end-user to the SP server with the response (optional operation state).
The flow is generally used when an enterprise has many vendors or partners with end-users that require access to an operator or partner SP resources, who is involved in maintaining their own databases.
End-users would typically obtain access to operator or partner SP resources through a web portal from within the IdP network enterprise security domain.
End-users clicks on a reference link on an IdP web portal which consists of protected resources at the SP. This would prompt the end-user to login via IdP (if not already logged in) and after a successful authorization flow, a SAML assertion (i.e., authentication flow) is transmitted to the Assertion Consumer Service (ACS) at the SP. The end-user would eventually gain access to the protected resource on the SP.
SP initiated flow
In this flow, the federation SSO deployment is initiated from the SP server by creating an authentication request and then redirecting the end-user to an IdP server with the a message and a string value which represents operation state.
The flow typically starts with an end-user requesting access to an operator or partner SP resources. The SP server redirects the end-user to an IdP server requesting for authentication. Once the end-user is authenticated, then the IdP server generates a SAML assertion with all the required attributes. The assertion is transmitted to the SP server via browser (i.e., user agent) and the end-user is granted access to the resources.
Glossary
Service Provider (SP)
A system or component that enables services to an end-user.
Identity Provider (IdP)
A system or component that maintains the identity information of end-users, such as name, password and other trivial data.
Entity ID
A unique ID that enables SP server and IdP server to identify each other.
Assertion
A unique user ID possessed by an IdP server and transmitted to SP server for end-users authentication processes. (e.g., e-mail address)
Assertion Consumer Service (ACS) URL
ACS URL is provided by the SP server. An IdP server will transmit SAML response to ACS URL.
Single Sign-On (SSO)
An authentication service that provides an end-user with a single login access for multiple web sites or client applications (e.g., name and password).
Binding
A standard that defines how to transport a profile message using specific protocols (e.g., HTTP)
Subject Type
A subject type specifies value that the SP expects. (e.g., username, userID).
Name ID
It is a format where name ID is specified. The format specified must be same the on both IdP and SP servers respectively.
Issue Instant
Timestamp to specify the time when it was generated.
Issuer
The identity or name of the SP.
In Response To
An identifier of a SAML request that a response belongs to.
Recipient
The identity or name of the SP.
Metadata
A set of data (XML format) provided by an IdP server to the SP server and/or vice versa.