Clever Engineering Blog — Always a Student

SAML Protocol

By Keith Richards on

A tool for Identity Federation

Security Assertion Markup Language, or SAML, is an open standard for exchanging authentication and authorization data between two parties. It’s a common strategy for single sign-on (SSO), allowing users to sign in once and authenticate with multiple third party applications. Similar to OAuth2.0, SAML promotes data security by preventing direct access to sensitive user information. It also means users can track a single set of login credentials rather than managing one set per application.

History Lesson

SAML was first developed in the early 2000s by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS). It was developed in response to the growing trend of web applications and the need for users to access multiple applications with a single set of credentials. Before SAML, each application would typically have its own authentication system, requiring users to enter their username and password for each application separately. This was not only inconvenient for users but also made it difficult for organizations to manage user access and permissions across multiple applications. SAML was designed to address these issues by providing a standard protocol for exchanging authentication and authorization data between parties. 

The first version of SAML, SAML 1.0, was released in 2002. It provided a basic framework for authentication and authorization. SAML 1.1 was released in 2003 and addressed some limitations identified in the earlier version, but it was still limited in its capabilities. SAML 2.0, which was released in 2005, represented a major overhaul of the protocol. It introduced a number of new features, such as support for metadata, improved support for single sign-on, and improved support for attribute exchange. Since its release, SAML 2.0 has seen wide adoption as an authentication standard.

Attendance

There are two primary roles in a SAML exchange, the Service Providers (SP) and Identity Provider (IdP).

  • Service Providers are the services or applications users wish to use. They coordinate with Identity Providers to authorize users and grant access to protected resources.
  • Identity Providers are responsible for authenticating the user and sharing authorization information to SPs. Identity Providers package the users information into a well-known format known as a SAML Assertion.

How SAML Works

Both SP and IdP can initiate authorization into an application. If a user visits the application first, the application (or SP in SAML terms) will ask the Identity Provider for information about the user, then use that information to process the login. This is known as an SP-initiated authorization. If the user first visits their SSO application (or IdP) then navigates to an application from a list of approved applications, the IdP will simply forward information to the Service Provider. The application can then use this information to proceed. This is known as an IdP-initiated authorization.

Crucially, IdPs and SPs must establish a trust relationship before any exchange can happen. That is, IdPs will only share information with SPs that it knows. The trust relationship prevents sensitive data from being released to bad actors.

SP-Initiated Authentication

IdP-Initiated Authentication

Real World Scenario

In previous installments of this series, we talked about an educators conference. The conference limited seminar attendance based on attendees’ roles. Some sessions were specific to school administrators, while others were tailored toward specific subjects. All attendees wore a color-coded lanyard that granted access to sessions relevant to their role in the district.

Conference attendees can get their badges and lanyards in one of two ways. Checking in to the event involves contacting the event coordinators who then verify registration and out together the attendees packet with a badge and lanyard. Attendees can either check-in early with the event coordinators and have their packet ready for them at the venue, or they can check-in at the venue, who then contacts the event coordinators. Regardless of the check-in method, the end result remains the same- the attendee’s registration is verified and they have the necessary badges and lanyards to participate in seminars.

In this scenario, the event coordinator acts as the Identity Provider while the venue acts as the Service Provider. The packet put together by the event coordinator is similar to the SAML assertion. Attendees have two options for checking in. The first method, early check-in, is similar to IdP-initiated flow. The second method, checking in at the venue, is similar to the SP-initiated flow.

SAML is a crucial technology for organizations that need to manage user access to multiple applications. It provides a secure, centralized way to manage user authentication and authorization, and it enables organizations to improve the user experience and enhance security. The bidirectional system supports logins from applications as well as SSO organizations. Clever uses the SAML protocol both as a service provider (sign into Clever through a third party SSO) and an identity provider (sign into application partners through Clever).