SAML Assertion
An XML document containing authentication/attribute statements sent from IdP to SP in SAML flows.
What is SAML Assertion?
SAML Assertion is an XML document issued by an Identity Provider (IdP) to a Service Provider (SP) containing statements about the user.
Types of SAML assertions:
- Authentication Assertion: Confirms the user has authenticated (and how)
- Attribute Assertion: Provides user attributes (email, name, department, role)
- Authorization Assertion: Specifies what the user is allowed to do (less common)
Assertions are digitally signed by the IdP using XML Signature and can be encrypted using XML Encryption for additional security.
Analogy
Think of a SAML assertion like a digitally signed letter from your boss (IdP) to a security guard (SP). The letter says 'John is allowed in' (authentication), 'His department is Sales' (attributes), and 'He can enter the East Wing' (authorization) - all signed so the guard knows it's authentic.
Types and Use Cases
- "Enterprise SSO: IdP sends authentication + attribute assertions to Salesforce, Slack"
- "B2B Federation: Partner IdP sends assertions with user attributes to vendor portal"
- "Attribute Sharing: Assertions contain department, role, clearance level"
- "Federated Auth: Assertions prove authentication without password sharing"
How it Works
```xml
<!-- SAML Assertion Example -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_8e8dc5f69a98cc4c1ff3421e5ce34605"
IssueInstant="2023-01-15T12:00:00Z"
Version="2.0">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@company.com
</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>user@company.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="department">
<saml:AttributeValue>Sales</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="role">
<saml:AttributeValue>Manager</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
```
SAML Assertion vs OIDC ID Token (JWT)
SAML Assertion
OIDC ID Token (JWT)
SAML Assertion is XML-based (verbose, complex)
OIDC ID Token is JSON-based (compact, simple)
SAML uses XML Signature
OIDC uses JWT signature (compact)
SAML is enterprise-focused (older)
OIDC is modern (better mobile support)
Best Practices for SAML Assertion
- "Always validate signature: Verify the assertion is signed by the trusted IdP"
- "Check timestamps: Validate NotBefore and NotOnOrAfter to prevent replay attacks"
- "Use HTTPS + destination check: Ensure assertion is sent to the correct SP"
How LoginRadius Powers SAML Assertion
LoginRadius CIAM platform provides comprehensive SAML assertion handling: as IdP (send signed assertions to Salesforce, Workday, etc.), as SP (receive assertions from Okta, Azure AD), assertion signature validation, attribute mapping, and support for both IdP-initiated and SP-initiated flows. Our platform provides SAML test tools, assertion debugging APIs, and detailed SAML logs for audit and compliance.
FAQs
SAML Assertion is XML-based, verbose, uses XML Signature, and works via browser POST. OIDC ID Token is JSON-based (JWT), compact, uses JWT signature, and works via redirect/authorization code flow. SAML is older (enterprise), OIDC is modern (better mobile support, simpler implementation).
Steps: (1) Verify signature using IdP's public certificate (XML Signature), (2) Check issuer - is this from a trusted IdP?, (3) Check timestamps - NotBefore/NotOnOrAfter, (4) Validate audience - is your SP the intended recipient?, (5) Check session - is the authentication recent?
LoginRadius supports SAML assertions as both IdP (send assertions to third-party SPs) and SP (receive assertions from corporate IdPs). Our platform handles assertion signing/validation, attribute mapping, and supports both IdP-initiated and SP-initiated flows. LoginRadius also provides SAML test tools and detailed assertion logs for troubleshooting.