Metadata, Security Considerations & SAML vs. OIDC

Metadata & Attribute Mapping

SAML metadata — an XML document describing endpoints, certificates, and supported bindings — is how IdP and SP configure their trust relationship without manually entering every URL and cert. Different IdPs may name attributes differently (mail vs. email vs. EmailAddress), so the SP integration needs attribute mapping to its own user model.

JIT Provisioning & Single Logout

Just-In-Time provisioning creates or updates the SP's local user record automatically from assertion data on first login, avoiding a manual pre-creation step. Single Logout (SLO) propagates a logout at one SP (or the IdP) to terminate sessions across every other SP the user was signed into via SSO, since a user can be simultaneously authenticated across many apps.

Security: Signature Validation & Replay Protection

Skipping signature validation defeats SAML's core security guarantee — it would let an attacker forge or tamper with an assertion and impersonate any user. Assertions also include a unique ID and a validity window (NotBefore/NotOnOrAfter); SPs should reject expired or already-consumed assertion IDs to prevent replay attacks.

SAML vs. OIDC

SAML uses XML assertions exchanged via browser redirects/forms; OpenID Connect uses JSON Web Tokens built on OAuth2, generally lighter-weight and more REST/mobile-friendly. SAML predates OIDC and remains deeply embedded in enterprise B2B and internal corporate SSO, while OIDC/OAuth2 dominates newer, especially mobile and API-first, applications.

SAML in Front of LDAP/Active Directory

A common enterprise pattern: the IdP handles authenticating against an underlying LDAP/Active Directory internally, while every downstream application just consumes standardized SAML assertions — rather than each application reimplementing LDAP bind/query logic itself.