What is SAML (Security Assertion Markup Language)?

SAML is an open communication standard of the identity provider (IdP) that transmits authenticated user information to the service provider. SSO - It is one of the indispensable communication structures for Single Sign-On.

SAML uses XML as the communication language and communication structure. By encrypting all or part of the data, it ensures the communication and data integrity between the IdP and the SP with a common certificate.

Before explaining this communication standard in detail, let's talk a little bit about the terms it uses as a “concept”.

Identity Provider (IdP)

SAML always has one IdP and one SP. IdP verifies the identity in this role, signing the prepared data and transmitting it to the SP. It performs this signing with a certificate. It shares the readable version of this certificate (Public Key) with SP beforehand.

There is a signing process here, but it’s optional. IdP and SP may agree that this communication should not be signed - which is definitely not a method we recommend. An unsigned communication can be copied and recreated by third-parties.

In the data generated by the IdP, there may be information belonging to the user such as User Name, Name, Surname, and Email address. But there is absolutely no information such as password data.

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 be mentioning the concepts of IdP Initiated and SP Initiated.

Service Provider (SP)

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 according to the situation.

One of the things SP's task is to do here is to check the signature of the data it contains with the certificate, even though it has read the data. If the data does not match the certificate signature, it should definitely not let the user in.

There can be many basic problems encountered between SP and IdP. The primary way to avoid and monitor these problems may be to use proven SAML libraries suitable for the language you are using.

The incoming data contains all the information required by the SP to let the user in.

Communication Certificate

Communication certificate is a structure that works with a private and a public public certificate. In this structure, a data signed with a private key can be verified with a public key.

When we think of communication in this point, we are talking about a signature data that is created with a private key and can be verified with a public key. In the scenario where we gave the public key to SP, the SP verified the information sent and actually sent this information to my IdP and can understand it.

IdP Initiated and SP Initiated

If you pay attention while describing the communication between IdP and SP, we always explained it as an information flow from IdP to SP. Actually, which side initiated the communication is very important here. These terms primarily describe this. IdP Initiated refers to communication initiated by IdP, and SP Initiated refers to communication initiated by SP.

There is a one-sided communication when the communication is initiated by the IdP. Because the information that has been prepared and to be transmitted to the user is already created by the IdP, the SP does not need to tell me to prepare this data. As a matter of fact, IdP sends the ready information directly to the SP via the Assertion Consumer URL we mentioned earlier. This submission is of course done by simple HTTP methods.

When this communication is initiated over SP, the SP first notifies the IdP of its intention (Intent). According to this intention, IdP SP returns the necessary answer. If you notice, while there is direct communication in IdP, in SP, there is a request that states the intention first, and then the response to which the IdP returns as the second request.

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 mostly used for SSO processing. One of the biggest benefits is saving the user a lot of time by saving the trouble of logging in again and again. With SSO, the user also knows from which application he is logged in (deduplicated session screen). There is only one screen to trust, where he must enter his username and password. By entering this information into different applications over and over again, you will prevent security weaknesses that occur.

A SAML Integration with Examples

Let's look at how SAML integration can be done with an example to examine the subject better.

We will do the example on MonoSign. You can perform this integration with the IdP you have used using similar settings.

For SP, we will use the Workplace application (Workplace workplaces is a platform prepared by Facebook and has SAML support). You can use any SP as an example as well.

MonoSign - Creating an application on (IdP)

MonoSign offers us screens on which we can quickly create our applications. I will perform the process of defining my application through these screens. I defined from MonoSign

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 so many settings you can make with SAML. At this point, using a minimal SAML solution may work for you at first, but then it will seriously block you.

Below you can view some of the settings MonoSign brings out 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