SAML

SAML is an XML-based standard for passing signed identity statements between an identity provider and an application. It commonly lets employees use one organizational sign-in to reach separate web applications without giving each application the organizational password.

itIdentity, access, and cryptography

Don't Panic — SAML

SAML is the formal arrangement by which one organization says, in signed XML, that a person has authenticated, and another application decides whether to let that person in. It exists because handing every application the organizational password would be a remarkably efficient way to create several problems at once. Instead, an identity provider, or IdP, does the authentication. A service provider, or SP, runs the application and creates its own session after checking the statement.

The browser plays courier. It carries an AuthnRequest from the SP to the IdP and often carries a response back to the SP's Assertion Consumer Service, the receiving endpoint. Couriers are useful, but they are not trust authorities. The SP must check the issuer, signature, audience, destination, time conditions, subject confirmation, and, when it started the request, the response correlation. A valid signature is necessary, which is SAML's polite way of saying it is not remotely the whole story.

The vocabulary looks like a small bureaucracy because it separates jobs. An assertion says something about a subject. A protocol supplies the request and response. A binding decides how messages travel, such as HTTP Redirect or HTTP POST. A profile combines those parts for a situation such as browser single sign-on. Metadata is the shared trust map: entity IDs, endpoints, bindings, and public keys. An entity ID may look like a URL, but it is an identifier, not an invitation to open it in a browser and wait for enlightenment.

The surprising part is that authentication and authorization remain different jobs. A NameID or attribute can identify a person, yet the application still decides which local account and role that identity may receive. Stable identifiers and allowlisted attribute mappings make that decision less excitable. Certificate rollover brings the same lesson in a different hat: both parties must accept the new trust material before the old key retires.

Read the Intro for the full sign-in flow and the checks that make an assertion acceptable. Use Slides when the four layers or the failure map have blurred into a distinguished fog. Keep the Cheatsheet nearby when comparing identifiers, bindings, validation checks, and troubleshooting signals. Field Notes covers the operational costs that tend to appear after the first successful redirect, when the integration has stopped being a diagram and started being somebody's responsibility.

Don't Panic — SAML

Relevant careers