What is SAML? A practical guide to federation and enterprise single sign-on

Privacy, security and identity

SAML means Security Assertion Markup Language. It is an XML-based federation standard used mainly for enterprise single sign-on. In a typical SAML setup, an identity provider authenticates the user and sends a signed assertion to a service provider, which then trusts that statement and grants access to the application. That is why SAML is common in staff access to SaaS tools. It centralises sign-in and makes it easier to manage joiners, movers and leavers. But SAML does not replace sensible permissions, certificate management or access reviews inside the application.

What this means

SAML is best understood as a trust mechanism between systems. Instead of every business application handling usernames, passwords and MFA on its own, a company can designate one service as the identity provider, often the corporate SSO platform. When a user tries to open a service provider, such as a payroll tool or customer support platform, that application sends the user to the identity provider. The identity provider checks who they are and then sends back a structured statement saying, in effect, "this person has been authenticated and here are the user details you asked for".

That statement is called an assertion. It can include an authentication statement showing when and how the user signed in, plus attributes such as email address, department or role identifier. The service provider uses the assertion to create a local session and decide how to map the user to an application account.

The result is not just convenience. It changes where identity is controlled. Password policy, MFA, logon branding, and account disablement can be managed centrally instead of separately in every tool. That is why SAML became so common in enterprise SaaS access, especially where organisations want staff to sign in through one corporate identity layer.

Why it matters

SAML matters because scattered local accounts create operational drag and security debt. If every SaaS product has its own passwords, reset process, MFA settings and user directory, then the organisation ends up with inconsistent sign-in rules and stale access that lingers after people move teams or leave. SAML helps move that control back to the identity provider, which means one stronger sign-in policy can protect many applications.

For leaders and operators, this is mainly about control and lifecycle management. When HR marks someone as a leaver, disabling the identity account can immediately cut off access to multiple connected services. When someone changes role, updates to the directory can feed through to the applications that rely on the identity provider. When you need stronger authentication for sensitive systems, you can often enforce it centrally at sign-in instead of relying on each vendor to implement the same standard well.

This also matters in AI-enabled environments. Many organisations now connect staff to internal assistants, knowledge tools, copilots and SaaS platforms containing valuable internal material. If those services trust the corporate identity provider through SAML, the business can keep authentication policy, MFA and deprovisioning in one place. That is much safer than running separate local accounts for each application.

The boundary is important, though. SAML helps a service provider trust that an identity provider authenticated a person. It does not define your whole permission model. A user can enter through SAML and still have the wrong rights, excessive roles, or stale entitlements inside the application. Central sign-in is not the same as central least privilege.

How it works

A common SAML web flow starts when a user opens a SaaS application. That application, acting as the service provider, sees that the user does not yet have a local session. It sends an authentication request to the identity provider. The user signs in there, possibly with MFA, and the identity provider creates a SAML response containing a SAML assertion. The assertion is digitally signed so the service provider can verify it came from a trusted source and was not modified in transit.

Inside the assertion are some key pieces. There is usually a subject, which identifies the user. There is an authentication statement, which says the user was authenticated and may include the time and method. There can also be attribute statements, such as name, email address, department or employee number. There are usually conditions too, including who the assertion is meant for and how long it is valid.

Those conditions are not just technical details. Audience restriction tells the receiving application which service provider the assertion was intended for. The service provider should reject an assertion intended for a different audience. Lifetime fields such as NotBefore and NotOnOrAfter stop assertions remaining valid indefinitely. InResponseTo and recipient fields help bind the response to the original flow and destination.

Trust depends on configuration. The service provider must know which identity provider it trusts and which signing certificate or metadata to use for validation. The identity provider and service provider both need accurate metadata, correct endpoints, correct certificates and agreed attributes. If you rotate certificates late, trust breaks. If you release the wrong attributes, the application may provision accounts incorrectly. If you fail to validate signatures, audience, or expiry, you do not really have federated security; you have an expensive assumption.

Examples

Consider a professional services firm using six cloud applications: Microsoft 365, HR software, a ticketing platform, an expenses tool, a wiki and a customer portal admin console. Before SAML, each system has separate local accounts. Offboarding depends on six manual tasks and two are usually missed. After moving those applications behind the company identity provider, a disabled staff identity stops normal access across the estate far more reliably. The service providers still keep their own sessions and roles, but the main sign-in gate is centralised.

Another example is a joiner process. A new employee joins the support team. HR creates the staff record, the directory assigns department and email attributes, and the identity provider becomes the sign-in source for the support suite. The support platform receives a SAML assertion with the agreed user attributes and creates or updates the local account automatically. That reduces friction for operations, but only if the attribute mapping is correct. If the wrong department value or entitlement feed is sent, the person can still land in the wrong access group.

A third example is stronger MFA for sensitive SaaS. A finance system accepts SAML from the company IdP. The business decides that ordinary staff can use authenticator-app MFA, but finance approvers and payroll admins must use phishing-resistant sign-in. Because the application trusts the IdP through SAML, the business can usually enforce that requirement at the IdP rather than asking the finance vendor to run a separate login stack.

There is also a misconfiguration example that matters. A team federates several apps through SAML but keeps old local application accounts as a fallback "just in case". Two years later, a contractor's local admin account is still active in one SaaS platform despite the contractor having left long ago. That is not a SAML failure in the protocol sense. It is a governance failure caused by incomplete migration and poor leaver discipline. SAML can centralise sign-in, but only if you actually retire or govern the local paths that remain.

Common misunderstandings

A frequent misunderstanding is that SAML is simply "SSO". SSO is the user experience of signing in once and then reaching multiple applications. SAML is one of the standards that can help deliver that experience. They are related, but not identical.

Another misunderstanding is that SAML manages all permissions. It does not. SAML assertions can carry attributes that help with access decisions, but they are not a substitute for the application's own role model, approval logic or entitlement reviews. A clean SAML login can still land someone in an over-privileged local role if your mappings are sloppy.

Some teams also assume that because the identity provider performed MFA, every downstream service is now secure by default. That only holds if the service provider is validating assertions properly, if the sign-in policies are actually strong enough for the risk, and if alternative login paths have not been left behind.

It is also easy to overstate the difference between SAML and OAuth. In practice, they solve different primary problems. SAML is heavily used for enterprise federation and browser-based SSO into applications. OAuth is about delegated authorisation to APIs and resources. OpenID Connect adds identity on top of OAuth. There is overlap in real systems, but replacing one explanation with the other usually confuses non-specialists.

Finally, people sometimes think certificate configuration is just plumbing. In SAML, certificate trust is a central security control. If the service provider trusts the wrong signing certificate or fails to update metadata safely, an attacker or misconfiguration can undermine the whole arrangement.

Risks and boundaries

The biggest risk area in SAML is misplaced trust. The service provider is choosing to trust statements from the identity provider, so signature validation, certificate handling and metadata management are central, not optional. If the service provider accepts unsigned or badly validated responses, or if it trusts the wrong certificate, the protocol has been reduced to theatre.

Assertion validation is another critical boundary. Signed assertions still need correct checks for issuer, audience, recipient, expiry and replay. A validly signed assertion intended for one application should not be accepted by another. A previously valid assertion should not create a fresh session after it expires. A response should not become reusable just because the service provider never checks uniqueness.

Attribute release creates a more operational risk. Teams often start by sending many attributes because it seems easier than designing carefully. That can leak more personal data than needed or create brittle account provisioning that depends on values nobody governs well. Minimal, deliberate attribute release is usually safer than "send everything and see what the app does".

Certificate lifecycle is another practical pain point. SAML trust often depends on signing certificates and metadata URLs. If rotation is unmanaged, applications break on Monday morning and someone is tempted to apply an insecure temporary fix. If metadata is delivered or updated insecurely, trust can be subverted. If private signing keys are poorly protected, an attacker can mint assertions that service providers may accept.

There is also a governance boundary after sign-in. SAML can make it easier to remove access centrally, but stale local roles within the service provider can still persist. A leaver may lose SAML sign-in yet keep API keys, local service accounts, or previously provisioned admin privileges inside the application if reviews are weak.

For UK organisations, SAML can support cleaner control over staff access to systems containing personal data, but it is not a compliance badge. It remains a federation and sign-in mechanism. You still need entitlement reviews, logging, application-level role design and lifecycle controls.

What to do next

Begin by identifying which business applications should trust your corporate identity provider and which are still running on local logins. That inventory matters more than abstract protocol debates. If the application holds sensitive personal data, finance operations, customer communications or internal knowledge for AI tools, ask whether it should still have a separate password database at all.

Next, inspect the joiner, mover and leaver process around each federated application. Do roles map correctly? Are local fallback accounts still present? Are contractors and temporary staff removed cleanly? Central sign-in only pays off when lifecycle controls are equally central and verified.

Then review the federation configuration itself. Ask who owns certificate rotation, how metadata is distributed, how assertion failure is monitored, and whether negative testing is performed. In plain English: do you know the application rejects the wrong assertions, or do you only know that valid users can still sign in?

After that, reduce unnecessary attribute release. Send the minimum user information the service provider genuinely needs. That is cleaner for privacy, simpler for operations and less fragile when directory fields change.

Finally, keep the boundary clear for stakeholders. Use SAML for trusted sign-in and federation. Use role design, RBAC or ABAC, periodic access reviews, and application governance for what happens after login. That distinction prevents a surprising amount of confusion and misplaced assurance.

FAQs

Is SAML outdated?

SAML is older than some newer identity standards, but "older" does not mean irrelevant. It remains widely used for enterprise SSO into SaaS applications, especially in workforce environments. The better question is whether it fits the use case. For browser-based staff access to business applications, it often still does. For API delegation and modern mobile patterns, OAuth and OpenID Connect are usually more natural.

Does SAML mean we can switch off all local accounts in every application?

That is often a good target, but not always an immediate reality. Some applications keep local emergency accounts, service identities or API-specific credentials. The important thing is to know what remains and govern it deliberately. The usual failure is assuming federation solved the whole problem while local fallback accounts, old admins or unmanaged tokens continue to exist outside the SAML path.

If we use SAML, do we still need MFA?

Usually yes, and often more than before. SAML centralises trust in the identity provider, which means the authentication taking place there becomes more important, not less. A strong SAML design typically pairs federation with strong MFA at the identity provider, especially for privileged users and sensitive applications. Federation without strong authentication simply centralises weak sign-in.

Sources

‹ What is MFA? A practical guide to multi-factor authentication

What is OAuth? A practical guide to delegated authorisation ›