SAML 2.0
IdentityServer can participate in SAML 2.0 in two distinct roles: as a SAML 2.0 Identity Provider (IdP), issuing SAML assertions to other Service Providers (SPs), or as a Service Provider. Understanding which role you need determines which part of the documentation to follow.
Most deployments use one role or the other, but both can be active at the same time.
When to Use SAML 2.0
Section titled “When to Use SAML 2.0”SAML 2.0 support is useful when:
- You need to integrate with enterprise SaaS applications that require SAML (e.g., Salesforce, Workday, ServiceNow)
- You are migrating from a legacy SSO system that uses SAML
- Your organization has compliance or procurement requirements for using SAML
For new integrations, OpenID Connect is the better choice. SAML 2.0 is provided for when you need to work with existing SAML-based systems.
If you are new to SAML 2.0 or want a refresher on the protocol’s core building blocks, see SAML 2.0 Concepts for an overview of assertions, bindings, metadata, name identifiers, and other key concepts before diving into configuration.
Acting as an Identity Provider
Section titled “Acting as an Identity Provider”When IdentityServer acts as an Identity Provider (IdP), it issues SAML assertions to Service Providers. Service Providers redirect users to IdentityServer for authentication, and IdentityServer returns a signed SAML assertion confirming the user’s identity.
This is the most common setup. You configure IdentityServer to trust one or more SPs, and those SPs delegate authentication to IdentityServer.
Acting as a Service Provider
Section titled “Acting as a Service Provider”When IdentityServer acts as a Service Provider (SP), it consumes SAML assertions from an external IdP. IdentityServer redirects users to the external IdP for authentication, then processes the resulting assertion to establish a local session.
This is useful when you need to federate with enterprise systems like ADFS or Shibboleth. In this setup, IdentityServer is a consumer of SAML, not a producer.