Introduction

There are various methods of SSO (single sign-on), and SAML is widely used among them, but do you know how SAML works?
　
In this blog, I will introduce "SAML Assertion" which is an important element in understanding SAML.

What is SAML?

SAML stands for "Security Assertion Markup Language" and is a protocol based on XML. Used during SSO with a web application when the application delegates authentication to an external authentication service (IdP).
SAML is realized by mutual trust between the IdP (Identity Provider) and SP (Service Provider) through the user (web browser).

So how does the SP actually trust the IdP?
The answer is a certificate. Let's take a closer look in the next chapter.

What are SAML Assertions?

A SAML assertion is a message that contains information such as user credentials, attributes, and privileges. The IdP issues a SAML assertion after authenticating the user and verifying attributes and privileges, and the SP receives the SAML assertion.
　
When the SP receives the SAML assertion, it needs to trust the IdP. In doing so, the SP checks to see if the received SAML assertion was signed with the correct certificate.
　
The SP must have the IdP's certificate in advance to ensure the signature of the SAML assertion is correct here.

The three pieces of information included in the SAML assertion are:

• Authentication Assertion: information such as the time and place of authentication
• Attribute Assertion (attribution): Attribute information such as the user's name, age, etc.
• Authorization Decision Assertion (authorization): Information about a user's privileges, such as file access rights

Okta SAML Assertion

I actually observed Okta's SAML assertions using Google Chrome's SAML Tracer.
The SAML assertion that can be confirmed with SAML Tracer is as shown below.

SAML Assertion when accessing Slack with IdP-initiated

The statement "saml2:AuthnStatement" is the authentication assertion, and the statement "saml2:AttributeStatement" is the attribute assertion.
　
Looking at Okta's SAML Assertions, we can see that it does not contain Authorization Decision Assertions, it contains Authentication Assertions and Attribute Assertions.
　
Below is the authentication assertion part of the SAML assertion. From "2021-11-18T23:43:29.317Z" you can see when the user was authenticated.
Also, since there is a description of "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", we know that the IdP authenticated the user using a password.

We can see that the attribute assertion contains the email address, full name, and username information.

One of the important pieces of information included in the SAML assertion is the NameID.

To authenticate with SAML, you need information about how your IdP and SP define users.
For example, if the SP uses the email address to identify the user, and the IdP uses the user ID, when the email address and the email address as the user ID are different, the SP side and The user on the IdP side cannot be linked and cannot be authenticated.
　
NameID is used by IdPs and SPs to tell how a user is defined.
　
There are various formats for Name ID, as shown below.

• Unspecified
  Description: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
• email address
  Description: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
• X.509 Subject Name
  Description: urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
• Windows Domain Qualified Names
  Description: urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
• Kerberos principal names
  Description: urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
• Persistent Identifier
  Description: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• Transient Identifier
  Description: urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Okta's SAML assertion states "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, so we know we are using the Persistent Identifier NameID format.
A Persistent Identifier defines a user with a persistent identifier that always uses the same identifier for a single user.
In other words, there is a user-specific identifier in Okta to link the user between the IdP and SP.

Summary

This time, we observed Okta's SAML assertions. What do you think?
We introduced the SAML assertion when accessing Slack with IdP-initiated, but the information described in the SAML assertion will be different depending on the situation, such as accessing with SPinitiated or accessing another SP.

As you learn about SAML, it's interesting to observe the actual SAML assertions being sent.