A SAML assertion is a digitally signed XML document that serves as a user’s credential for Single Sign-On (SSO) via the Security Assertion Markup Language (SAML) protocol.
It’s issued by a trusted Identity Provider (IdP) — like Okta, Azure AD, or Ping Identity — and sent to a Service Provider (SP) — like IDC’s platform — to confirm that a user is authenticated and permitted to access a specific service.
| Element | Purpose |
| Issuer | Identifies the IdP that generated the assertion |
| Subject | Contains the user’s identity (usually an email or username) |
| Conditions | Defines the validity window and any access restrictions |
| AuthnStatement | Confirms that the user was authenticated and specifies the method (e.g., password, multifactor) |
| AttributeStatement | Optional user attributes like role, department, or region |
Authentication Flow Using SAML
- User requests access to a resource like IDC Research.
- IDC (acting as SP) redirects the user to the IdP.
- IdP authenticates the user (e.g., via SSO credentials).
- IdP issues a SAML assertion and sends it back to IDC.
- IDC validates the signature and grants access based on the user’s entitlements.
Example of a SAML Assertion (simplified)
<saml:Assertion ...>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">hjk89-uuid-ojfd-1234-userid
</saml:NameID>
...
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<saml:AttributeValue>john.doe@yourcompany.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<saml:AttributeValue>John</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<saml:AttributeValue>Doe</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/claims/CommonName">
<saml:AttributeValue>John Doe</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
This sample contains all that IDC needs to authenticate a user. When IDC’s SP receives such assertion, it will either match John Doe to an existing user (by NameID or email) or create a new account if not found, then log them in.
Before moving on, double-check that your IdP is releasing those attributes to IDC. Some IdPs require you to explicitly permit sending email, name, etc., especially if using a cloud IdP like Azure AD (which might only send a name identifier by default). In ADFS, after trust setup, you explicitly create rules as described.