Building on the architecture, we now examine the 'SAML Assertion.' An assertion is a signed XML document that the IdP provides to the SP to prove a user's identity and provide specific attributes about that user.
Not all assertions are created equal. Depending on the needs of the Service Provider, the IdP can issue different types of claims within the XML structure.
| Assertion Type | Purpose | Example Claim |
|---|---|---|
| Authentication Assertion | Confirms the user logged in | AuthnInstant: 2023-10-01T10:00Z |
| Attribute Assertion | Provides user data (Roles, Email) | Role: 'Global-Admin' |
| Authorization Decision | Confirms if user has a specific right | Decision: 'Permit' |
The most common combination is an Authentication assertion paired with an Attribute statement, which tells the SP who the user is and what group they belong to in the corporate directory.
π‘ The most critical elements are the `<Subject>` (who the user is) and the `<Conditions>` (when the token expires).
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID>john.doe@example.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2023-10-01T09:00Z" NotOnOrAfter="2023-10-01T10:00Z" />
<saml:AttributeStatement>
<saml:Attribute Name="groups">
<saml:AttributeValue>IT_Security_Team</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature>...</ds:Signature>
</saml:Assertion>The XML above is a simplified assertion. The `<ds:Signature>` block ensures that the SP can verify that the IdPβand only the IdPβcreated this document.
If an SP does not validate the `NotOnOrAfter` condition, a captured assertion could be re-used indefinitely (Replay Attack).
Avoid putting extremely sensitive data (like PII) in assertions unless the assertion is encrypted using the SP's public key.
Verify exercises to earn β 200 XP and unlock next lab level.