SAML SSO Configuration for Enterprise Identity Federation
Security & Identity
SAML SSO connects an enterprise identity provider (Azure AD, Okta, ADFS) to a service provider (SaaS application, internal portal). Getting the configuration right the first time avoids a frustrating cycle of certificate errors and attribute mapping failures.
Key Patterns & Steps
- Trust is established by exchanging metadata XMLs between IdP and SP — never skip validating the metadata before testing
- SP-initiated vs IdP-initiated: most enterprise apps prefer SP-initiated (user clicks login, SP redirects to IdP) — support both
- Attribute mapping: the SP expects specific claim names (email, givenName, surname, groups) — match them exactly in the IdP configuration
- Certificate rotation: SAML signing certificates expire — document expiry dates and set calendar reminders 60 days ahead
- NameID format: most SPs accept EmailAddress or Persistent — match what the SP documentation specifies
- Troubleshoot with SAML-tracer browser extension: decode the SAML assertion in flight to see exactly what the IdP is sending
Lessons Learned
The most common SSO failure I debug is an attribute mismatch — the IdP sends "mail" but the SP expects "email". Always test with SAML-tracer before escalating to the application vendor.
Technologies
← Back to Architecture Notes