Skip to main content
DataRidge
Category: Access Control

Security Assertion Markup Language

Also known as:
Simply put

SAML is an open, XML-based standard that lets people sign in once and then access multiple web applications without logging in separately to each one. It works by having a trusted identity system vouch for a user's identity to the applications they want to use, enabling single sign-on (SSO). This entry describes what SAML is and how it functions at a conceptual level; it does not cover specific implementation configurations, cryptographic details, or how SAML interacts with data protection obligations.

Formal definition

SAML (Security Assertion Markup Language) is an open, XML-based standard for exchanging authentication and authorization data between parties, most commonly between an identity provider (IdP) and a service provider (SP). The IdP issues security assertions, XML statements that an SP uses to make access-control decisions, thereby enabling web-based single sign-on (SSO) in which a user authenticates once and gains access to multiple applications. This definition addresses SAML's role as an authentication and assertion-exchange protocol only; the evidence provided does not establish protocol version specifics, binding and profile details, signature and encryption requirements, or any relationship to particular data protection regimes, and those aspects are out of scope here.

Why it matters

SAML underpins much of the enterprise single sign-on (SSO) that organizations rely on to let users authenticate once and reach multiple web applications. From a governance and access-management perspective, this matters because centralizing authentication through a trusted identity provider (IdP) can reduce the number of separate credential stores an organization must manage and can give a single point at which access decisions are made. Where authentication is federated in this way, the identity provider becomes a critical control point whose configuration and trustworthiness directly affect which users reach which applications.

Because SAML concentrates authentication at the identity provider, the design and operation of that provider carries significant weight. The standard enables a service provider (SP) to make access-control decisions based on assertions issued by an IdP, so the integrity of that trust relationship is central to how access is granted. This entry does not establish signature, encryption, binding, or profile requirements, and it does not address how those elements should be configured; those are important but out of scope here based on the evidence provided.

SAML is an authentication and assertion-exchange mechanism, not a data protection control. It governs how identity is asserted between parties, and should not be treated as addressing lawful basis, retention, cross-border transfer, or other data protection obligations. The evidence provided does not establish any relationship between SAML and specific data protection regimes, and no such relationship should be inferred from this entry.

Who it's relevant to

Identity and access management teams
Teams responsible for authentication and federated access work directly with the identity provider and service provider relationships that SAML defines. Because the identity provider vouches for user identity across multiple applications, its configuration and trust relationships are a core operational concern for these teams.
Security architects and engineers
Those designing enterprise access architectures need to understand SAML's role as an assertion-exchange protocol that centralizes authentication at the identity provider. Note that this entry does not cover cryptographic, binding, or profile details, which such practitioners would need to address separately when implementing SAML.
Information governance and compliance leads
Governance leads should recognize SAML as an authentication mechanism, not a data protection or governance control in itself. It does not, on its own, satisfy data protection obligations, and accountability for access decisions still requires demonstrable evidence of how identity trust and access are managed. The relationship between SAML and any particular data protection regime is out of scope here.

Inside SAML

Assertion
An XML-based statement issued by an identity provider conveying authentication, attribute, or authorization decision information about a subject to a relying party.
Identity Provider (IdP)
The party that authenticates the user and issues SAML assertions. It holds responsibility for verifying identity and asserting attributes to service providers.
Service Provider (SP)
The relying party that consumes SAML assertions to grant access to a resource or application without directly authenticating the user itself.
Subject
The principal (typically a user) that the assertion describes, identified by a name identifier that may be persistent, transient, or pseudonymous depending on configuration.
Bindings
The transport mechanisms that define how SAML protocol messages are carried over underlying communication protocols, such as HTTP Redirect or HTTP POST.
Metadata
Configuration information exchanged between IdP and SP describing endpoints, supported bindings, and signing or encryption keys used to establish trust.
Single Sign-On (SSO) Profile
A defined combination of assertions, protocols, and bindings that enables a user to authenticate once and access multiple federated services.

Common questions

Answers to the questions practitioners most commonly ask about SAML.

Does implementing SAML by itself make an organization compliant with data protection requirements?
No. SAML is a federated authentication and single sign-on protocol; it addresses how identity assertions are exchanged between an identity provider and a service provider. It does not, on its own, satisfy data protection obligations. Compliance depends on context, jurisdiction, and implementation, including how personal data in assertions is handled, the lawful basis for processing, retention, and the broader control environment. Treat SAML as one technical control that supports, but does not guarantee, compliance.
Is SAML an authorization mechanism that decides what a user is permitted to do?
Not primarily. SAML is chiefly concerned with authentication and conveying identity assertions between parties. While assertions can carry attributes that downstream systems use for access decisions, SAML does not itself define or enforce authorization policy. The relying service provider generally remains responsible for making and enforcing access control decisions, and that accountability requires demonstrable evidence rather than reliance on the assertion alone.
What roles are involved in a typical SAML exchange, and who bears responsibility for each?
A SAML flow generally involves an identity provider, which authenticates the user and issues assertions, and a service provider, which relies on those assertions to grant access. Each party is typically responsible for the security and correct configuration of its own components. Where personal data is exchanged, the allocation of controller and processor obligations depends on the relationship and arrangements between the organizations and should be assessed separately; this entry does not resolve that allocation.
What personal data considerations arise when SAML assertions carry user attributes?
Assertions may include identifiers and attributes that constitute personal data, and in some cases attributes could fall within special category or sensitive data categories, which typically attract heightened obligations. Organizations generally should limit the attributes released to those necessary for the service, document the basis for processing, and consider retention and logging of assertions. Encryption or transformation of assertion contents does not, by itself, render the data non-personal.
What security controls are commonly associated with a SAML deployment?
Common measures generally include validating assertion signatures, protecting the confidentiality and integrity of assertions in transit, managing certificate and key lifecycles, constraining assertion validity windows, and validating audience and destination fields. These fall largely within the information security domain of confidentiality, integrity, and availability, and they complement but do not replace governance activities such as attribute ownership and policy. The specific controls appropriate to a deployment depend on its risk profile.
How should a SAML integration be documented for accountability purposes?
Where personal data is processed, organizations typically maintain records describing the attributes exchanged, the parties involved, and the purpose, consistent with applicable governance and record-keeping obligations. Accountability generally requires demonstrable evidence, such as configuration records, metadata agreements, and logs, rather than stated intent alone. This entry does not address cross-border transfer mechanics, retention schedules, or enforcement outcomes, which should be evaluated separately under the relevant regime.

Common misconceptions

SAML and OAuth 2.0 (or OpenID Connect) are interchangeable protocols that solve the same problem.
SAML is generally an authentication and federation framework centered on XML assertions, whereas OAuth 2.0 is an authorization framework and OpenID Connect is an identity layer built on it. They address overlapping but distinct concerns, and selection depends on context and implementation rather than one being a drop-in replacement for another.
Implementing SAML SSO by itself makes an organization compliant with data protection obligations.
SAML is a technical authentication and federation mechanism; it does not by itself establish a lawful basis for processing, satisfy accountability requirements, or address retention, transfer, or subject rights. Compliance depends on jurisdiction, context, and demonstrable governance evidence beyond the protocol.
Attributes exchanged in SAML assertions are not personal data because they are transient or pseudonymous.
Identifiers and attributes conveyed in assertions typically relate to identifiable individuals and generally remain personal data in most jurisdictions. Pseudonymous name identifiers are reversible and therefore usually still fall within scope rather than being anonymized or out of scope.

Best practices

Sign SAML assertions and, where sensitive attributes are conveyed, encrypt them, treating assertion contents that relate to identifiable individuals as personal data subject to applicable obligations.
Establish and regularly verify trust through exchanged metadata, rotating signing and encryption keys and validating IdP and SP endpoints to prevent misconfiguration.
Minimize the attributes released in assertions to only those needed by the service provider, applying data minimization principles rather than passing broad user profiles by default.
Prefer persistent or transient pseudonymous name identifiers where appropriate, while documenting that such identifiers generally remain personal data and do not amount to anonymization.
Maintain demonstrable records of the roles, trust relationships, and attribute flows between identity provider and service providers to support accountability, since stated intent alone is generally insufficient.
Assess and document data protection considerations of federation arrangements separately, recognizing that this configuration does not by itself address cross-border transfer mechanics, retention, or subject rights.