SAML is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). Which means that you can use one set of credentials to log into many different websites. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management (CRM) software, Active Directory, etc.
SAML transactions use Extensible Markup Language (XML) for standardized communications between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service.
What is SAML used for?
SAML adoption allows IT shops to use software as a service (SaaS) solutions while maintaining a secure centralized identity management system.
SAML implements a secure method of passing user authentications and authorizations between the identity provider and service providers. When a user logs into a SAML enabled application, the service provider requests authorization from the appropriate identity provider. The identity provider authenticates the user’s credentials and then returns the authorization for the user to the service provider, and the user is now able to use the application.
SAML authentication is the process of verifying the user’s identity and credentials (password, two-factor authentication, etc.). SAML authorization tells the service provider what access to grant the authenticated user.
What is a SAML Provider?
A SAML provider is a system that helps a user access a service they need. There are two primary types of SAML providers: service provider, and identity provider.
A service provider needs the authentication from the identity provider to grant authorization to the user.
An identity provider performs the authentication that the end user is who they say they are and sends that data to the service provider along with the user’s access rights for the service.
Microsoft Active Directory or Azure are common identity providers. Salesforce and other CRM solutions are usually service providers, in that they depend on an identity provider for user authentication.
What is a SAML Assertion?
A SAML Assertion is the XML document that the identity provider sends to the service provider that contains the user authorization. There are three different types of SAML Assertions — authentication, attribute, and authorization decision.
- Authentication assertions prove identification of the user and provide the time the user logged in and what method of authentication they used (I.e., Kerberos, 2 factor, etc.)
- The attribution assertion passes the SAML attributes to the service provider — SAML attributes are specific pieces of data that provide information about the user.
- An authorization decision assertion says if the user is authorized to use the service or if the identity provider denied their request due to a password failure or lack of rights to the service.
How does SAML work?
SAML works by passing information about users, logins, and attributes between the identity provider and service providers. Each user logs in once to Single Sign On with the identity provider, and then the identity provider can pass SAML attributes to the service provider when the user attempts to access those services. The service provider requests the authorization and authentication from the identity provider. Since both of those systems speak the same language — SAML — the user only needs to log in once.
Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.
SAML vs OAuth
OAuth is a protocol for authorization: it ensures user have access privileges. SAML is a protocol for authentication: it ensures the end user is who they say they are.
An identity provider (IdP) or SSO service can use both in conjunction with each other, or OAuth alone (although using OAuth for authentication is considered “pseudo-authentication”).
To summarize: SAML and OAuth are different protocols and are used for different purposes, but both are often used with SSO.
