User SSO through SAML Assertion
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.
Key Components of a SAML Assertion
| 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 |
How It Works in Practice
- 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 SAML Assertion (simplified):
1. xml
CopyEdit
<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 contains all that IDC needs. When IDC’s SP receives this, it will either match John Doe to an existing user (by NameID or email) or create a new account if not found, then log him 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.