SAML is an open communication standard through which the identity provider (IdP) transmits authenticated user information to the service provider. It is one of the indispensable communication structures for single sign-on (SSO).
SAML uses XML as its communication language and structure. By signing or encrypting all or part of the data, it ensures the integrity of the communication and data between the IdP and the SP with a shared certificate.
Before explaining this communication standard in detail, let's talk a little about the terms it uses as concepts.
Identity provider (IdP)
SAML always has one IdP and one SP. In this role, the IdP verifies the identity, signs the prepared data and transmits it to the SP. It performs this signing with a certificate, and shares the readable version of this certificate (the public key) with the SP beforehand.
There is a signing process here, but it's optional. The IdP and SP may agree that this communication should not be signed — which is definitely not a method we recommend. Unsigned communication can be copied and recreated by third parties.
The data generated by the IdP may contain information belonging to the user, such as username, name, surname and email address. But it never contains information such as password data.
The IdP transmits this information to an address they have agreed upon. The SAML equivalent of this address is known as the Assertion Consumer URL. After the IdP transmits the information to the SP, the IdP's task is finished.
In the following sections, we will mention the concepts of IdP-initiated and SP-initiated flows.
Service provider (SP)
The SP, on the other hand, checks whether the identity data sent by the IdP meets certain requirements. Afterwards, it decides what to do with the user information contained in it and lets the user in accordingly.
One of the SP's tasks here is to check the signature of the data against the certificate, even after it has read the data. If the data does not match the certificate signature, it should definitely not let the user in.
There are many basic problems that can be encountered between the SP and the IdP. The primary way to avoid and monitor these problems is to use proven SAML libraries suitable for the language you are using.
The incoming data contains all the information the SP requires to let the user in.
Communication certificate
The communication certificate is a structure that works with a private and a public certificate. In this structure, data signed with the private key can be verified with the public key.
When we think of the communication at this point, we are talking about a signature that is created with the private key and can be verified with the public key. In the scenario where we gave the public key to the SP, the SP can verify that the information it received was really sent by the IdP.
IdP-initiated and SP-initiated
If you paid attention while we described the communication between the IdP and the SP, we always explained it as an information flow from the IdP to the SP. Actually, which side initiated the communication is very important here, and these terms describe exactly that. IdP-initiated refers to communication initiated by the IdP, and SP-initiated refers to communication initiated by the SP.
There is one-way communication when the flow is initiated by the IdP. Because the information to be transmitted is already created by the IdP, the SP does not need to ask the IdP to prepare this data. The IdP sends the ready information directly to the SP via the Assertion Consumer URL we mentioned earlier. This submission is, of course, done via simple HTTP methods.
When the communication is initiated by the SP, the SP first notifies the IdP of its intent. Based on this intent, the IdP returns the necessary answer to the SP. Notice that while the IdP-initiated flow is a single direct communication, the SP-initiated flow consists of a first request stating the intent, followed by the IdP's response as a second step.
Single sign-on
While reviewing SAML, you will come across a lot of single sign-on (SSO) topics. This is because SAML is one of the session mechanisms most commonly used for SSO. One of its biggest benefits is saving the user a lot of time by removing the trouble of logging in again and again. With SSO, the user also always knows which screen they are logging in from — there is only one screen to trust, where they must enter their username and password. Not entering these credentials into different applications over and over again prevents the security weaknesses that would otherwise occur.
A SAML integration with examples
Let's look at how a SAML integration can be done with an example, to examine the subject better.
We will do the example with Monosign. You can perform this integration with the IdP you use, with similar settings.
For the SP, we will use the Workplace application (Workplace is a collaboration platform built by Facebook, with SAML support). You can use any SP for your own example as well.
Creating an application in Monosign (IdP)
Monosign offers screens on which we can quickly create our applications. I defined my application through these screens.
I can also view the application from my applications screen and access it with a single click, without typing a username and password (IdP-initiated single sign-on).
See the application in the application list
We can see the application we created directly in the list.
Monosign identity provider settings
There are many settings you can configure with SAML. A minimal SAML solution may work for you at first, but it will seriously limit you later on.
Below you can view some of the settings Monosign offers for SAML.
Sources
You can find all the features related to SAML by reviewing the RFC below. You can access SAML's RFC at https://tools.ietf.org/html/rfc7522
