SAML v2

Overview

Adding a Login button for a third-party SAML v2 Identity Provider to FusionAuth is simple. This guide will walk you through the steps necessary to enable a SAML v2 Identity Provider.

In this example FusionAuth is the SAML service provider and we are configuring a connection to a SAML Identity Provider which will be the system of record for user data.

We also provide specific examples for configuring SAML with some providers whose implementation requires unique configuration. If you’d like us to provide additional examples, please open a request on GitHub.

• Configure SAML v2 for Active Directory Federation Services (ADFS)
• Configure SAML v2 for Okta

Once you have completed this configuration you will be able to enable the SAML v2 login button for one or more FusionAuth Applications. Below is an example login page with a SAML v2 Identity Provider enabled for PiedPiper.

Create a SAML v2 Identity Provider

To create an Identity Provider navigate to Settings -> Identity Providers and click Add provider and select SAML v2 from the dialog.

This will take you to the Add SAML v2 screen. Here you will need to fill out the required fields. If you do not know the IdP endpoint of your SAML v2 provider, you will need to contact the identity provider owner to get the URL.

To enable this identity provider for an application, find your application name in the Applications configuration section at the bottom of this panel. You will always see the FusionAuth application, this application represents the FusionAuth administrative user interface. If you wish to be able to log into FusionAuth with this provider, you may enable this application.

In the following screenshot you will see that we have enabled this login provider for the Pied Piper application and enabled Create registration. Enabling create registration means that a user does not need to be manually registered for the application prior to using this login provider.

For example, when a new user attempts to log into Pied Piper using SAMLv2, if their user does not exist in FusionAuth it will be created dynamically, and if the Create registration toggle has been enabled, the user will also be registered for Pied Piper and assigned any default roles assigned by the application.

If you do not wish to automatically provision a user for this application when logging in with SAMLv2, leave Create registration off. You will need to manually register a user for this application before they may Sign in with SAMLv2.

That's it, now the 'Login with PiedPiper' button will show up on the login page.

Form Fields

Options

Form Fields

Managed domains

Form Fields

Integration Details

After configuring the Identity Provider, FusionAuth will display values likely required by your SAML v2 Identity Provider to trust FusionAuth as a relying party. Do so by navigating to Settings -> Identity Providers and click the green magnifying glass on your SAML provider.

When viewing the details, scroll to the SAML v2 Integration details section. There you will find the necessary values to configure an integration with a SAMLv2 IdP.

SAML v2 Integration Details

Fields

CORS Configuration

To complete the login request, the SAML v2 Identity Provider will make an HTTP POST request to the callback URL in FusionAuth. In order for this request to be allowed through the CORS filter you will need to navigate to Settings -> System -> CORS and add the SAML IdP origin as an Allowed Origin the CORS configuration.

Once you complete your SAML v2 Identity Provider configuration, if your CORS configuration is not yet configured to allow the login request to complete you will be shown the following warning prompting you to complete the CORS configuration. See CORS Filter reference for additional details on modifying the CORS configuration.

Troubleshooting

A common pattern is to set up SAML as the login method for the FusionAuth application. This lets you keep all your users in the SAML system, and have FusionAuth delegate auth decisions to it. However, if your Identity Provider isn’t configured correctly, you can end up in a dead end, unable to log in. This might happen if the following occurs:

• You set up SAML as the authentication method for your FusionAuth admin application.
• You set the Managed domains to your domain. For example, example.com.
• All added users have the same example.com domain.
• You accidentally misconfigure SAML and break authentication.
• Then you log out of the FusionAuth administrative user interface.

You won’t be able to log in to the FusionAuth admin application to correct the misconfiguration. You’ve locked down the FusionAuth admin application so that only users with example.com email domains can access it, but because of the misconfiguration, there is no account with a valid SAML login.

This is a problem, but not an insurmountable one. Your options depend on when you discover the issue. If you are beginning your SAML configuration, you can avoid this scenario. Follow these steps:

• Don’t set any value of Managed domains before you have tested the SAML configuration.
• Test authentication in a different or incognito browser window, ensuring that an admin user account is always accessible to modify configuration.
• Add an admin user account with a domain not in the Managed domains setting. Ensure this user is registered with the FusionAuth admin application and has the admin role.
• Set up an API key. Navigate to Settings -> API Keys to do so and make sure it has privileges to create users and registrations. This will open up options in the future to reset settings without using the administrative user interface.

If you are currently locked out of your FusionAuth application, you have fewer options:

• If you have a known username and password that are not delegated to SAML (perhaps the initial account created when you set up FusionAuth) proceed to the FusionAuth admin login page. Append &showPasswordField=true to the end of the login URL. This will force the UI to show the password field.
• If you have an API key with appropriate privileges, you can modify the configuration without using the administrative user interface. Add an admin user with a different email domain and sign into the admin interface to correct your SAML configuration. Here’s how you might do so (3c219e58-ed0e-4b18-ad48-f4f92793ae32 is the FusionAuth application Id):

Adding a New Admin User With a Different Domain

curl -XPOST -H "Authorization: $API_KEY" -H "Content-Type: application/json" \
-d '{
	"user": {
		"email": "user@differentdomain.com",
		"password": "password"
	},
	"registration": {
		"applicationId": "3c219e58-ed0e-4b18-ad48-f4f92793ae32",
		"roles": ["admin"]
	}
}' \
https://login.piedpiper.com/api/user/registration

If you have neither an API key nor a known user, you can restore from a database backup, modify the database directly if you have access, or re-install FusionAuth.

Troubleshooting SAML Flows

To troubleshoot, turn on the Debug option and then navigate to System -> Event Log.

Proceed through the SAML flow and review the Event log entries to see if there are any configuration issues.

Limitations

FusionAuth supports SAML both as a SAML Identity Provider (IdP) and as a Service Provider (SP). The SP implementation has certain limitations.

Version 2.0 is supported; other SAML versions are unsupported.

FusionAuth supports the following NameID format values by default:

• urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

You may also provide your own format name. To determine the correct value, please examine the supported values of the software package for which you are configuring FusionAuth as the SP.

Map between SAML claims and user claims using a reconcile lambda or FusionAuth SAMLv2 Identity Provider configuration.

FusionAuth supports the following SAMLv2 bindings:

• HTTP Redirect
• HTTP POST

Other bindings are not supported.