SAML/Enterprise SSO

PropelAuth’s SAML SSO support allows your users to connect their organizations to their own identity provider. We currently provide integrations for Google, Okta, Entra, OneLogin, JumpCloud, Duo, and Rippling. However, we also offer a generic SAML integration that will work with any IdP that supports SAML.

One of the best things about our SAML integration is that your code doesn’t need to change at all when you close your first enterprise customer. SAML is an implementation detail of how an organization manages their users within your product. Any code you write that deals with organizations will work, regardless of the method that organization uses to manage its members.

Enabling SAML in Your Project

To enable SAML for your PropelAuth project, go to the Signup / Login page in your PropelAuth dashboard.

Enabling SAML For Organizations

Once you've enabled SAML on the project-level, you can choose which of your organization should have access by going to the Organizations page and select an organization, select Settings, then toggling the "Can this organization set up SAML?" setting.

Alternatively, you can enable SAML for an organization programmatically via the Enable SAML for Org API call.

Your Customers Configure their own SAML

PropelAuth empowers your customers to setup SAML themselves - providing them with a detailed guide for each of our IdP integrations.

Any user with the manage a SAML / Enterprise SSO connection for their organization permission can start the process of connecting to their identity provider. This starts in your user's account page in their organization's settings tab.

Alternatively, you can navigate to an organization's settings page and click on the Generate Link button. This button will generate a link to allow an employee of an organization to set up SAML. This link does not require authentication to access and is intended to be used by an employee of the org, such as a member of their IT team.

Mapping Roles via SAML

Your users also have the option to map roles from their IdP to your application. Each IdP is a bit different so we offer guides for each provider that we support. Most of the time, the mapping will occur either from using roles or groups. For example, if a user is an Owner for your app in Okta, they'll be mapped to the Owner role in your app.

Alternatively, if a user is a member of the role_Owner group in Okta, they'll then be mapped to the Owner role in your app. The guides we provide for your users will provide all the information they need (including the names of your roles) to map roles from their identity provder to your app.

Editing SAML Login Settings

There are three different options for how the login experience will look for your SAML users. You can select these options in the Signup / Login page under Enterprise SSO/SAML Login.

• By Org Name - The default option. When your users visit your login page, they'll first click a Sign in with SSO button. They'll then be prompted to enter the name of their organization, such as "Acme Inc". If there's a match they'll automatically be redirected to their IdP to login.

• By domain - Similar to the above example where the user will first click on a Sign in with SSO button. Then, they'll be prompted to enter their email address. If the domain of the email address matches the Organization Domain (found in the org's settings page), they'll automatically be redirected to their identity provider.

• Default to SAML login - You can also choose if you want to set SAML as the default login method, meaning no Sign in with SSO button. Instead, PropelAuth will automatically check if an email address belongs to a SAML enabled org. If it does not, it'll fall back to password login.

Redirecting users directly to their SAML provider

While our hosted pages have multiple ways to redirect your users to their IdP, sometimes you want to skip the hosted pages and redirect them directly to their SAML provider. To do this, you can direct your users to {AUTH_URL}/api/fe/v3/login/saml and then include one of the following query parameters:

• domain - Redirects the user to the SAML login page for an organization with a matching domain
• email - Parses the domain from the email address and redirects the user to the SAML login page for an organization with a matching domain
• org_id - Redirects the user to the SAML login page for the provided organization
• org_name (case sensitive) - Redirects the user to the SAML login page for the provided organization

An example of this would look like so:

{AUTH_URL}/api/fe/v3/login/saml?email=test@acmeinc.com

If the provided organization has SAML enabled, the user will be redirected to their IdP. Otherwise, it will fall back to redirecting the user to your login page.

Generic SAML (Other)

Don't see your customer's SAML provider on our supported list? Your users also have the option to connect to a generic SAML provider. We guide your customers through three steps:

1. We provide a ACS URL and SP Entity ID that can be entered into the identity provider during setup.

2. We guide your users into mapping user attributes from the identity provider to your app.

3. We require the user to provide the IDP SSO URL, Entity ID, and Certificate from the identity provider. Note that the names of these variables may differ across providers.