The Security Assertion Markup Language (SAML) protocol is an open-standard, XML-based framework for authentication and authorization between two entities without a password:

• Service provider (SP) agrees to trust the identity provider to authenticate users.

• Identity provider (IdP) authenticates users and provides to service providers an authentication assertion that indicates a user has been authenticated.

Auth0 supports the SAML protocol and can serve as the IdP, the SP, or both including:

• SAML2 web applications

• SAML SSO integrations

• IdP-initiated SSO

• Microsoft Active Directory Federation Services (ADFS)

• SAML request signing and encrypting

Auth0 supports the following SAML bindings:

• HTTP Redirect

• HTTP POST

Auth0 supports the following SAML options:

• Web Browser SSO Profile

• Single Logout Profile

• Name Identifier Management Profile

• Name Identifier Mapping Profile

Applications, especially custom ones, can authenticate users against an external IdP using protocols such as OpenID Connect (OIDC) or OAuth 2.0. However, you might want to leverage an enterprise SAML provider for authentication, even if you wrote your application to use either protocol.

Some applications (such as Salesforce, Box, and Workday) allow users to authenticate against an external IdP using the SAML protocol. You can then integrate the application with Auth0, which serves as the application's SAML IdP. Application users will be redirected to Auth0 to log in, and Auth0 can authenticate them using any backend authentication connection, such as an LDAP directory, a database, or another SAML IdP or Social Provider. Once the user is authenticated, Auth0 returns a SAML assertion to the application that indicates such.

Here is a list of IdP services known to support the SAML protocol. There may be additional services beyond what is shown below. The following providers have participated in a Kantara interoperability test and are therefore likely to conform well to the SAML spec.

• adAS

• ADFS

• Dot Net Workflow

• Elastic SSO Team & Enterprise

• Entrust GetAccess & IdentityGuard (check protocol supported)

• EIC (check protocol supported)

• Ilex Sign&go

• iWelcome

• NetIQ Access Manager

• OpenAM

• RCDevs Open SAMPL IdP

• Optimal IdM VIS Federation Services

• Oracle Access Manager (Oracle Identity Federation merged into this)

• PingFederate (IDP Light)

• RSA Federated Identity (IDP Light)

• SecureAuth

• Symplified

• Tivoli Federated Identity Manager

• TrustBuilder

• Ubisecure SSO

• WSO2 Identity Server

Auth0 provides specific instructions to configure the following SAML identity providers with Auth0:

• ADFS

• Okta

• OneLogin

• PingFederate 7

• Salesforce

• SiteMinder

• SSOCircle

If Auth0 serves as the service provider in a SAML federation, Auth0 can route authentication requests to an identity provider without already having an account pre-created for a specific user. Using the assertion returned by the identity provider, Auth0 can capture information needed to create a user profile for the user (this process is sometimes called just-in-time provisioning). To learn more, read Select from Multiple Connection Options.

Even though Auth0 doesn't require pre-created user accounts prior to the authentication process, the application integrated with Auth0 might. If this is the case, you have several options when it comes to handling this:

• After the identity provider creates the user, you can use an out-of-band process can create the accompanying user in the application (or Auth0) and add any user profile attributes required by the application. If, after authentication, any attributes are missing in the profile, the application can obtain them from the appropriate source and store them in the Auth0 user profile. The additional attributes are then sent to the application (in addition to any added by the identity provider) the next time the user logs in.

• You can use an Auth0 rule to call an API to retrieve any missing information and dynamically add it to the Auth0 profile (which is then returned to the application). Rules execute after successful authentication, and your application can retrieve profile attributes each time or you can save the attributes to the Auth0 profile.

• Auth0 can pass the basic profile information from the identity provider to the application, which then retrieves any missing information from another source. With the two sets of information, the application creates a local user profile.

You can specify email domains as part of the Auth0 SAMLP Connection configuration to control the IDP that handles a select group of users. For example, if you add email domain example.com to the Auth0 SAMLP Connection configuration for Company X, all users with emails with the example.com domain get handled by the specific IDP for Company X.

If Auth0 serves as the identity provider in a SAML federation, user accounts may be created multiple ways:

• Using a back-end authentication system, such as an LDAP directory, a database, or another SAML identity provider.

• Using the Auth0 Dashboard.

• Calling the Auth0 Management API.

• Implementing self-service user signup.

If your application is written to retrieve user profile information from a local store, you'll need to create the local profile after the accounts have been created in Auth0. Some of the ways you might do this include:

• An out-of-band process creating user profiles in the application;

• An Auth0 rule that executes on first login that calls an application API to create the user profile in the application;

• Modifying the application to create user profiles dynamically, based on information in the SAML assertion.

You can use Auth0 as both the SAML service provider and the SAML identity provider for testing purposes.

• SAML SSO Integrations
• Configure Auth0 as SAML Service Provider
• Configure Auth0 as SAML Identity Provider
• Test SAML SSO with Auth0 as Service Provider and Identity Provider
• SAML Identity Provider Configuration Settings
• Customize SAML Assertions