Security Assertion Markup Language (SAML)

The Issuer element uniquely identifies the Identity Provider (IdP) that created and digitally signed the assertion, typically a URI. The Subject element identifies the principal (user or service) the assertion is about.

• Subject Confirmation: Specifies how the subject was authenticated (e.g., bearer token, holder-of-key) and may include conditions like a time window for validity.
• NameID: A common format within the Subject, containing the user's identifier (e.g., email, persistent ID) in a specified format (urn:oasis:names:tc:SAML:2.0:nameid-format:email).

The Conditions element defines the validity constraints for the entire assertion. If any condition is not met, the Service Provider (SP) must reject the assertion.

Key conditions include:

• NotBefore & NotOnOrAfter: Define the exact time window during which the assertion is valid.
• Audience Restriction: Limits the assertion's consumption to specific, intended Service Providers (SPs) by listing their URIs. This prevents token replay attacks.
• OneTimeUse: An optional directive stating the assertion must be used immediately and cannot be used again.

The Authentication Statement (<saml:AuthnStatement>) provides proof that the subject was authenticated by the IdP at a specific time and using a specific method.

• AuthnInstant: The UTC timestamp of the authentication event.
• SessionIndex: An optional identifier for the user's session at the IdP, useful for single logout (SLO) scenarios.
• AuthnContext: Specifies the authentication context, detailing the method used (e.g., urn:oasis:names:tc:SAML:2.0:ac:classes:Password, urn:oasis:names:tc:SAML:2.0:ac:classes:X509, or urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos). This allows SPs to enforce policy-based access based on authentication strength.

The Attribute Statement (<saml:AttributeStatement>) carries specific claims about the subject in the form of name-value pairs. This is the primary mechanism for user provisioning and passing authorization data.

• Attributes are defined by a Name (a URI) and contain one or more string values.
• Common examples include email, firstName, lastName, department, group, or role.
• The SP uses these attributes to personalize the user experience, make access control decisions (e.g., via Role-Based Access Control), or populate local user profiles.

The Authorization Decision Statement (<saml:AuthzDecisionStatement>) is a legacy component where the IdP makes a direct access control decision for a specific resource. It answers whether the subject is permitted to perform a given action (e.g., Read, Write, Execute) on a specified resource (identified by a URI).

• Important Note: This statement type is rarely used in modern SAML 2.0 SSO implementations. Authorization is typically delegated to the SP, which uses the attributes from the Attribute Statement to make its own, context-aware decisions. Its presence indicates a more centralized, older authorization model.

A digital signature, applied using XML Signature (XMLSig), is a critical security component. It is typically applied over the entire assertion to ensure its integrity, authenticity, and non-repudiation.

• Integrity: Guarantees the assertion has not been tampered with in transit.
• Authenticity: Verifies the assertion originated from the trusted IdP.
• The signature is validated by the SP using the IdP's public certificate. The assertion is rejected if the signature is invalid or missing (unless an alternative transport-level security like TLS is mutually agreed upon).