SAML Explained: Assertions, IdP and SP Roles for the Security+ Exam

SAML — Security Assertion Markup Language — is the XML standard behind most enterprise single sign-on. Shibboleth is one well-known implementation, widely used in higher education federations; the underlying protocol is what the exam tests.

The two roles

Identity provider (IdP). Authenticates the user and issues assertions about them. Your organisation's directory or SSO platform.

Service provider (SP). The application the user wants to reach. It trusts assertions from the IdP rather than authenticating the user itself.

The user is the principal. The relationship rests on a pre-established trust: the SP holds the IdP's signing certificate and metadata, so it can verify that an assertion genuinely came from that IdP.

The property that matters: the user's password never reaches the service provider. Credentials are only ever presented to the IdP, which is why federation reduces credential exposure across dozens of applications.

Assertions

A SAML assertion is a signed XML document making statements about the principal. Three kinds:

Authentication assertion — this user was authenticated, at this time, by this method.
Attribute assertion — attributes about the user, such as department, role or email.
Authorisation decision assertion — whether the user may perform an action. Rarely used in practice; authorisation is normally left to the SP based on attributes.

The attribute assertion is what carries group membership and role information, which is how an application decides what the user may do without holding its own account for them.

The flows

SP-initiated. The user goes to the application first. The SP finds no session, redirects the browser to the IdP with an authentication request, the user authenticates, and the IdP posts a signed assertion back to the SP's assertion consumer service. The SP validates it and creates a session. This is the common case.

IdP-initiated. The user starts at a portal, selects an application, and the IdP posts an assertion to the SP unprompted.

The distinction matters for security: IdP-initiated flows have no request to correlate the response against, which makes them more exposed to assertion replay and injection. SP-initiated with proper request correlation is preferred.

Note also that the browser is the intermediary. The IdP and SP typically never talk directly; assertions travel via redirects and form posts through the user's browser. That is why assertions must be signed — the transport is not trusted.

Where SAML goes wrong

Worth knowing, because these appear in CySA+ scenarios.

Missing or improper signature validation. An SP that does not verify the signature, or verifies it on the wrong element, will accept forged assertions. Historically the most damaging class of SAML flaw.

XML signature wrapping. An attacker restructures the document so the signature validates against a legitimate fragment while the SP reads attacker-controlled content elsewhere. Defeated by validating that the signed element is the one actually processed.

XXE. SAML is XML, so an SP parsing assertions with external entity resolution enabled is exposed to file disclosure and internal requests. Disable DTD and external entity processing in the parser.

Assertion replay. Mitigated by short validity windows, one-time use enforcement, and correlating the InResponseTo value with the original request.

Missing audience restriction. An assertion intended for one SP being accepted by another. The audience element must be validated.

The common theme: the assertion is data from an untrusted transport, and every field that establishes its legitimacy must actually be checked.

SAML versus OIDC

	SAML 2.0	OpenID Connect
Format	XML assertions	JSON Web Tokens
Transport	Browser redirects and form posts	REST over HTTPS
Strength	Enterprise web SSO, rich attributes	Mobile, single-page apps, APIs
Maturity	Long established, widely supported	Newer, lighter

Both achieve federated authentication. SAML remains entrenched in enterprise and academic applications; OIDC dominates anything mobile or API-driven. Many organisations run both.

Federations

Shibboleth's particular context. A federation is a group of organisations agreeing to trust each other's identity providers under common rules, with metadata distributed centrally. A researcher at one university can reach a resource at another, or a licensed publisher, using their home credentials.

The operational benefit is that each institution manages only its own users, and the resource never holds accounts for people it does not employ.

What to remember

The IdP authenticates and issues signed XML assertions; the SP trusts them and never sees the password. Assertions may be authentication, attribute or authorisation decision statements. SP-initiated flows are preferred over IdP-initiated because the response can be correlated with a request. Signature validation, audience restriction and disabling XML external entities are the critical SP-side controls.

Related reading: Federation: SAML, OAuth and OIDC · OAuth 2.0 and OpenID Connect · JSON, XML and YAML