What Is Security Assertion Markup Language? Security Definition

Imagine you work for a company that uses many different online services, like an email system, a project management tool, and a payroll website. Without SAML, you would need a separate username and password for each of those services. You would have to log in to each one individually, and each service would need to store your password securely.

SAML changes this by creating a single login point, often called an identity provider. When you log in to the identity provider (for example, your company's main login portal), that provider creates a special digital document called a SAML assertion. This assertion is like a digital ID card that contains your name, a timestamp, and what systems you are allowed to access. When you then try to use the project management tool, that tool asks the identity provider for this digital ID card. The identity provider gives it to the project management tool, which checks the card's signature to make sure it is genuine. If everything is valid, you are allowed into the project management tool without needing to log in again.

This is called single sign-on, or SSO. SAML is one of the main technologies that makes SSO work across different companies and services on the internet. It uses XML (a structured text format) to write the digital ID cards, and it uses digital signatures and sometimes encryption to keep the information secure. The identity provider and the service provider agree on how to exchange these assertions ahead of time, so that trust is established before any login happens.

SAML is an XML-based open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It is defined by the OASIS Security Services Technical Committee and is currently at version 2.0, which is the most widely adopted version. The core concept is that the IdP authenticates the user and produces a SAML assertion, which is an XML document that contains statements about the user's identity, attributes, and permissions.

The SAML assertion comes in three main types: authentication statements (confirming the user logged in), attribute statements (providing details like email or role), and authorization decision statements (granting or denying access to a resource). The assertion is digitally signed using XML Signature, which ensures the SP can verify that the assertion really came from the trusted IdP and was not tampered with. Optionally, the assertion can also be encrypted using XML Encryption to protect sensitive data in transit.

SAML supports several different communication flows, called bindings. The most common is the Web Browser SSO Profile, where the user's browser is used to relay the assertion. In this flow, the user first attempts to access a resource at the SP. The SP redirects the user to the IdP with an authentication request. The user authenticates at the IdP (for example, by entering a password and a second factor). The IdP then generates a SAML assertion and sends it back to the user's browser, often via an HTTP POST form or a redirect. The browser forwards the assertion to the SP, which validates the signature, checks the timestamps, and grants access.

Other bindings include the Artifact Resolution profile (which uses a short reference called an artifact instead of the full assertion) and the Single Logout profile (which allows a user to sign out of all services at once). SAML also defines metadata documents that IdPs and SPs exchange to configure trust, including certificates, endpoints, and supported bindings. In real-world IT environments, SAML is implemented in products like Microsoft Active Directory Federation Services, Okta, Ping Identity, and many cloud-based applications. Configuration involves setting up a trust relationship between the IdP and SP by exchanging metadata and certificates.

SAML matters in real IT work because it solves a fundamental problem: how to manage user identities across many different systems without requiring users to remember dozens of passwords. In a typical enterprise, employees use email, customer relationship management software, human resources systems, file storage, and dozens of other applications. Without SAML, IT administrators would have to create and manage user accounts in every single system. When an employee leaves, they would need to be removed from every system individually, which is time-consuming and error-prone.

With SAML, the identity provider becomes a single point of control. When a new employee is hired, the IT team creates one account in the IdP. That employee can then access all SAML-enabled applications with a single login. When an employee leaves, disabling the account in the IdP immediately blocks access to all connected services. This dramatically reduces administrative overhead and improves security by eliminating orphaned accounts.

In cybersecurity, SAML helps prevent password fatigue and reduces the risk of phishing. Users do not need to type their passwords into every application; they only authenticate at the IdP. This means that even if a service provider's login page is compromised, the attacker cannot steal the user's password because the password is never sent to the SP. SAML also supports multi-factor authentication at the IdP level, so administrators can enforce MFA once and it applies to all connected services.

In cloud infrastructure and system administration, SAML is used to federate identities between organisations. For example, a company using Amazon Web Services (AWS) can configure SAML so that employees log in with their corporate credentials instead of creating separate IAM users. This is called identity federation. It allows organisations to maintain control over user identities while giving employees access to external cloud resources. SAML is also widely used in higher education (such as the InCommon federation) and government systems, where different agencies need to share access to resources without managing separate accounts.

In certification exams, SAML appears in several question formats. The most common is the scenario question. For example: A company has 500 employees who use a cloud-based customer relationship management tool and an email system. The company wants employees to log in once with their corporate credentials and have access to both systems without re-entering passwords. Which technology should the administrator implement? The correct answer is SAML, often with the explanation that it enables single sign-on.

Another common question type is the compare-and-contrast question. For instance: Which of the following is a key difference between SAML and OAuth? The answer might be that SAML is primarily for authentication while OAuth is for authorisation, or that SAML uses XML while OAuth uses JSON.

Architecture questions ask you to identify the components. A typical question might show a diagram where a user browser, an identity provider, and a service provider are connected with arrows. The question may ask: In this SAML SSO flow, what is the role of the identity provider? The answer is that the IdP authenticates the user and issues a SAML assertion.

Troubleshooting questions are less common but can appear. For example: Users report that they cannot access a cloud application after the IT team replaced the SAML identity provider's certificate. What is the most likely cause? The answer is that the service provider still has the old certificate and cannot validate the new SAML assertion's signature.

Some questions test knowledge of SAML bindings. For example: In which SAML binding does the user's browser send the assertion to the service provider using an HTML form? The answer is the HTTP POST binding.

Finally, security-focused questions might ask about SAML vulnerabilities. For example: An attacker intercepts a SAML assertion and attempts to reuse it to gain access. What SAML feature prevents this? The answer is the timestamp and the NotOnOrAfter attribute, which limits the assertion's validity window. Other questions might mention XML signature wrapping attacks or the importance of validating the entire assertion, not just the signature.

SAML is a cornerstone of identity federation in enterprise IT. When you work as a system administrator or security professional, you will encounter SAML in the context of configuring single sign-on for cloud applications. The key practical skill is understanding how to set up a trust relationship between an identity provider (IdP) and a service provider (SP).

First, you need to choose an IdP. Common choices include Microsoft Entra ID (formerly Azure AD), Okta, Ping Identity, or even open-source solutions like Keycloak. The IdP is the central authentication server. You also need to identify the SPs, which are the applications your users need to access, such as Salesforce, Workday, or AWS.

To configure SAML, you exchange metadata between the IdP and SP. Metadata is an XML document that contains information like the IdP's public certificate, its SSO endpoint URL, and the supported bindings. The SP also provides its own metadata, including its assertion consumer service (ACS) URL, which is the endpoint where it expects to receive SAML assertions. You import the IdP metadata into the SP, and sometimes import SP metadata into the IdP. This establishes mutual trust.

One common issue in practice is certificate expiration. The IdP signs assertions with a certificate that has an expiry date. If the certificate expires and the SP still has the old certificate, all SSO attempts will fail because the signature validation will fail. Administrators must rotate certificates before they expire and update the SP with the new certificate. Some modern IdPs allow automatic metadata refresh to handle this.

Another practical consideration is attribute mapping. The IdP sends attributes (like email, role, or department) as part of the SAML assertion. The SP needs to map these attributes to its own user fields. For example, the IdP might send an attribute called 'mail' but the SP expects 'email'. If the mapping is wrong, users may authenticate but then see errors or be denied access.

Security professionals must also be aware of SAML vulnerabilities. One known issue is the XML signature wrapping attack, where an attacker manipulates the XML structure so that the SP validates the signature on a legitimate part of the document but uses a different part for authorization decisions. Proper validation involves checking that the signed element truly corresponds to the assertion being processed. Other best practices include using short assertion lifetimes (typically 5-15 minutes), requiring SSL/TLS for all SAML endpoints, and implementing single logout so that terminating a session at the IdP also ends sessions at all SPs.

SAML connects to broader IT concepts like identity and access management (IAM), federation, and zero trust architectures. In a zero trust model, SAML helps ensure that users are authenticated and authorised before accessing any resource, even if they are on the corporate network. Understanding SAML is also a stepping stone to learning about modern alternatives like OpenID Connect, which build on similar concepts but use lighter-weight formats.