Security Assertion Markup Language, or primarily known by its abbreviated form—SAML, is an open standard that allows authentication and authorization between two servers—Service Provider (SP) and Identity Provider (IdP). It essentially facilitates the process and does not carry out authentication or authorization in itself. It uses XML- eXtensible Markup Language for the communication of these transactions.
Today, primarily, the newer version, which is SAML 2.0, is in use, which was approved by the Oasis Consortium in 2005. SAML enables secure usage of SaaS applications in the Federated Identity Management System and is also the leading protocol for web-based Single Sign-On.
This read will provide you a high-level explanation to SAML, showing you the bigger picture to this open standard, which you probably interact with every day—if you use any Identity Management solution. And if you don’t, this will also tell you why you should invest in it.
Let’s get started!
What is SAML?
SAML provides the Service Provider (SP) with the confirmation from the Identity Provider (IdP) that the users who need access to SP are authenticated and authorized to it.
The Service Provider here refers to your everyday list of applications to which you need access. Be it Salesforce to manage your leads, Workday to manage your employee data or want to apply for your vacation, and any other application that you need.
Identity Providers (IdP) like Cross Identity are those who store your user identities, either using a directory or Cross Identity directory. They validate them when prompted, provide solutions like authentication, authorization which are the basis of SAML and every other functionality which an Identity and Access Management solution can offer.
And to drill it further down, authentication is ensuring the users are who they claim to be when they request access to applications.
Authorization is ensuring they are entitled to the access they need. You can further understand the difference between the two here.
SAML in real-life?
Apart from the above jargon, SAML can be co-related to various real-world examples to understand the underlying concept.
Essentially, SAML is every verification process that ever made you run around.
For example, when you got your driver’s license. Now, many of us probably did not even get it right the first time to rethink of the dreadful times, but let’s go back in memory for science.
You applied for your driver’s license to obtain after you’ve had your Learner’s Permit. Here, the resource you need is the Driver’s license issued by the State, who is the Service Provider. The driving inspector, the one who has to validate your driving skills, is the Identity Provider. The State redirects you to the Inspector to test your driving, and only once you have passed the authentication of your identity and are deemed as authorized to drive, you are redirected to receive your License. If you are not authorized, then maybe try again next time with better skills to pass the test.
Quite obviously, this example is meant to clarify the philosophy behind SAML, the actual process of both obtaining a license and a SAML authentication is ten folds more complicated.
What happens when SAML is up and running?
The user needs access to the necessary Service Provider, which is an application enabled by SAML—thus can no longer verify the user by merely allowing a login session. The SP sends a SAML request to the IdP, basically asking, “Hey, this person is trying to access my application, could you let me know if the user is legit? While you’re at it, could you also let me know if they are entitled to it?”. The IdP gladly accepts the request and gets to work to verify the legitimacy of the action. The IdP runs the authentication drills to authenticate the user, be it using credentials or any other form of Multi-Factor Authentication (based on what they know, who they are, what they have). On successful authentication, the user is now authorized to use the application, i.e., the Service Provider.
This series of actions take place with redirects. From the SP redirected to the user’s browser to the IdP, which further redirects it to the SP with the necessary data, which are the SAML assertions.
Let’s talk about the internal workings of SAML—in the SAML language.
When a user wants to use an application, their browser sends a request to the SP, which checks for cookies. If present, it checks if it is associated with an active session—and then authenticated to use it.
Else, the Service Provider sends across an IdP Metadata file, which is an XML document containing the configuration information for IdP. This data can be encrypted as well. The necessary redirects are made using this information, which carries the SAML Authentication Request.
The IdP receives this request, if there is an active session present with the user, IdP returns the SAML Response. If not, it merely carries out the authentication process on the user’s login page, once authenticated—the browser stores the session cookie.
The SAML assertion containing the authentication, attributes, and authorization is now sent to the Service Provider using a redirect, and the user will now be able to access the required application.
Authentication assertions signify the identity of the user, if they are indeed who they claim to be, the method of authentication, and other details relevant to the session.
Attributes provide some information on the user entity.
Authorization provides information about the user’s rights to use the application and whether they are entitled to use it or not.
The Service Provider, which depends on the Identity Provider for the SAML response, is the Relying Party, and the Identity Provider, which is authenticating the user, becomes the Asserting Party.
SAML itself does not drive its transport mechanism—it depends on HTTP, SOAP, and other internet protocols—these are SAML bindings.
The initiation of SAML is done in two ways:
IdP initiated SAML is when users login to the IdP. It is a login page or dashboard when they use Single Sign-On (SSO), which authenticates the user. After this, the SAML assertion is sent to the SP.
SP initiated SAML is when the user first attempts to log in to the application after which a SAML Request is sent to the IdP, and then after authentication, a SAML assertion is sent back to the SP.
Advantages of SAML:
- SAML enables secure communication between servers in Federated Identity Management, which is a practice of segregating the identities across various organizations and their applications. With SAML, these users within the various organizations can trust each other’s access.
- SAML is the backbone of most web-based Single Sign-On. Single Sign-On is when your user identities access all their applications with one single set of credentials.
- It decreases IT time by enabling user access to hundreds of applications with just one set of credentials. Here, the user is hassle-free from remembering those hundred application passwords—thus, no more chances of forgetting these passwords. Your IT personnel need not constantly engage in providing you means to reset your forgotten password.
- Enables secure password habits as the user has to remember only one password. Poor password habits, like noting them down on a piece of paper, invites trouble. Anybody sneaky enough can get a hold of it and hack your account. In a corporate environment, this means the entire corporate ecosystem is at risk.
SAML Alternatives
OAuth is another open standard that authorizes users, unlike SAML, which authenticates and authorizes users. OAuth allows you to create an account using your social identities like Google, Facebook, Twitter. It provides limited access to your social network to a website without having to create a password to authorize your identity to the site.
Now there is OpenID, which is used to authenticate a user. OpenID, as a layer over OAuth, can fill in for the missing “authentication” factor. It verifies the end-user using authentication factors.
Now, you know how SAML works on a high level, you can read further material to understand the nitty-gritty details of it.
https://help.salesforce.com/articleView?id=sso_saml.htm&type=5
https://github.com/jch/saml
http://saml.xml.org/saml-specifications
