SAML Configuration Options

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. See SAML Configuration Options for all the various configurations of SAML available with Auth0 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:

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).

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.

Protocols Auth0 as SAML SP and IdP Diagram

Docs

SAML Configuration Options

SAML Configuration Options

Supported SAML bindings and options

SAML service providers

SAML identity providers

Auth0 as service provider

Auth0 as identity provider

Test SAML SSO using Auth0 as service and identity provider

Keep reading

Was this article helpful?