Enboarder has Single Sign On (SSO) capabilities for Admins accessing the platform, as well as the stakeholders' in a workflow (i.e. managers accessing a sequence with content).

So... We can set up SSO, but what are the actual benefits?

Enboarder has Single Sign-On (SSO) capabilities for Admins accessing the platform, as well as stakeholders in a workflow (e.g., managers accessing a sequence with content).

If you set up SSO capabilities in Enboarder, you can create a seamless login experience for your Admins and Stakeholders alike!

No need to create another account using a name and email ID
The ability to choose which employees can access the account and with what role
Controlled by your SSO administrator and not managed directly within Enboarder
Easy access revocation if an employee leaves the company

Before you begin: Like anything worth doing, integrations take time. Please allow up to 4 weeks for this integration to be completed, this includes time for scoping, development and testing. You’ll also need to have a system expert and/or system administrator to assist in the completion of this integration.

How Does SSO Work?

SSO allows users to authenticate into Enboarder using credentials managed by your identity provider (IdP). SSO should work as soon as settings are configured in both your IdP and within Enboarder.

Although Enboarder supports the SAML 2.0 standard, the setup may vary depending on the identity provider in use. For example, Okta, Azure AD, and Google Workspace all have slightly different configuration steps.

Supported IdPs

Okta
Azure Active Directory
Google Workspace
Ping Identity
Others supporting SAML 2.0 or OAuth (Open Authorization) 2.0

Understanding SSO Access Types in Enboarder

Enboarder supports multiple types of user access via SSO, depending on the role and the interface being accessed. Each URL supports a different experience and is managed from a different area within the platform.

🔐 Admin Login URL (For Admin Users)

This URL is used by users who need access to Enboarder’s full administrative features like access to configuration, reporting, and workflow management. It is generated and maintained in the SSO Settings section of your Enboarder account.

Found in: Settings > Security and Privacy > Set up SSO Security

Share this link only with users who need administrative access to the platform.

📊 My Dashboard Login URL (For Stakeholders)

This URL is used by internal employees such as employees or stakeholders who interact with tasks assigned via Enboarder workflows. It provides access to a limited view called My Dashboard.

Found in: Settings > General Configuration > Login Page for 'My Dashboard'

📊 Workflow Participant Access

This access is typically for new hires or external users. Since they may not have corporate credentials, they receive a link to access their assigned experience. SSO is generally not required for these users unless they are part of your IdP and configured accordingly.

✅ We recommend making the My Dashboard login URL available as a tile or bookmark to all employees for easier access. For Admin login, each admin should individually bookmark the Admin SSO URL to ensure they use the correct entry point.

Quick Setup Summary

Enable SSO in Enboarder
Create a SAML (Security Assertion Markup Language) App in your IdP (Identity Provider): Okta, Azure, or Google Workspace
Map required attributes: Email, First Name, Last Name, Role
Assign users or groups

Test login access, role assignment, and session timeout

Getting Started

Step 1: Activate SSO in Enboarder

To enable SSO in Enboarder:

Navigate to: Settings > Security and Privacy > Set up SSO Security.

(Please note, if you can't see the SSO option, let your Customer Success Manager know - they need to activate it on your account).

You'll need to capture the following values to configure your identity provider:

Entity ID
ACS URL (Assertion Consumer Service URL)
Relay State (optional)
SSO Login URL (provided by your IdP)

Setting Up SSO with Identity Providers

For IT/System Admins: Follow the steps below for your organization’s identity provider.

🔵 Microsoft Azure Active Directory (Azure AD)

1. Navigate to Enterprise Applications > New Application > SAML

2. Enter Entity ID and ACS URL from Enboarder. Relay State is recommended.

3. Configure attribute mappings:

First Name
Last Name
Email
Role (e.g., Enboarderrole)

Below is an example using standard names from AD documentation:

4. Download the SAML certificate and copy content into Enboarder starting with:
“- - -BEGIN CERTIFICATE- - -” and ending with “- - -END CERTIFICATE- - -”

5. Input the Azure Login URL as Enboarder's IdP Login URL
6. Use Azure Identifier as the Issuer ID

For JIT (Just-In-Time) provisioning-style role assignment, use a role attribute like Enboarderrole

🟣 Okta

To integrate Okta with Enboarder, follow these steps:

1. Navigate to Applications > Create App Integration > SAML 2.0 and name the app (e.g., "Enboarder Admin").

2. In the SAML settings, enter the following values copied from Enboarder:

Single sign-on URL: paste Enboarder's ACS URL (Assertion Consumer Service URL)
Audience URI (SP Entity ID): paste Enboarder's Entity ID
Relay State (optional): from Enboarder if provided

3. Download the Okta metadata:

Navigate to the application’s Sign On tab
Right-click the Identity Provider metadata link and select Save As
Change the file name to metadata.xml if needed
Open the XML file in a text editor and copy:
- IdP Login URL
- Issuer ID / Entity ID
- X.509 Certificate (copy the full content)

4. In Enboarder:

Go to Settings > Security & Privacy > Set up SSO Security
Paste the values into the corresponding fields
Save the configuration

5. Under Attribute Statements (optional), add the following user attribute mappings:

email → user.email
firstName → user.firstName
lastName → user.lastName
Enboarderrole → (custom field defined in the next steps)

6. (Optional) To pass user role attributes:

Go to Directory > Profile Editor
Add a new attribute called role to the user profile
Populate this field in each user’s profile with values matching Enboarder roles (e.g., Super Admin, General Admin)
In the Okta application, under General > SAML Settings > Attribute Statements, map:
- Enboarderrole → user.role

7. Assign users or groups to the Okta application.

Once these steps are completed, Okta SSO should be live for your Enboarder account.

🔴 Google Workspace

Setting up SSO between Google Workspace and Enboarder requires creating a Custom SAML App and configuring identity and service provider details. It’s recommended to have both the Google Admin Console and Enboarder SSO settings open in separate tabs during setup.

Step-by-Step Instructions:

1. In Google Workspace, navigate to: Admin Console > Apps > Web and Mobile Apps > Add Custom SAML App

2. App Details

Enter a name for your app (e.g., “Enboarder SSO”)
Optionally upload a logo or icon
Click “Continue”

3. Google Identity Provider (IdP) Details

Copy the following values from Option 2 on this screen:
- SSO URL
- Entity ID
- Certificate (SHA-256 fingerprint is not needed)

4. In Enboarder

Navigate to Settings > Security and Privacy > Set up SSO Security
Paste the IdP SSO URL, Entity ID, and Certificate into the appropriate fields

5. Back in Google Workspace

Click “Continue” to reach the Service Provider Details screen
Copy the following values from Enboarder and paste them into the Google fields:
- ACS URL (Assertion Consumer Service URL)
- Entity ID
- Relay State (optional)

6. Configure Name ID Settings

Name ID Format: Recommended to use Email
Name ID: Select Primary email

7. Attribute Mapping

Define attributes and ensure they align with Enboarder field expectations:
- Primary Email
- First Name
- Last Name
- Role
(Optional) Add Group Membership if your access control depends on group-based roles

8. Final Configuration

In Enboarder, ensure the “Assertions Signed” box is checked
Save the configuration on both sides

Assigning Access

Option A: Individual Users

Assign the Enboarder app to specific users in your IdP. Here is a sample showing the application with the name 'dev.enboarder.net' being assigned to a single user in the SSO system, OKTA:

Here is a sample showing the application with the name 'dev.enboarder.net' being assigned to a single user in the SSO system, OKTA:

Option B: Groups

Assign via directory groups (e.g., Admins, Stakeholders). Here is a sample showing the application with the name 'dev.enboarder.net' being assigned to a group 'admin' in the SSO system, OKTA:

Option C: Universal Access

This option gives complete control to the SSO admin of the account to add and remove users, as well as allowing them to change their roles to access Enboarder within your SSO system. (This will also be used to provide stakeholder access to locked sequences and SSO login to My Dashboard)

Assign/ manage roles of users through your Enboarder account's SSO attributes

2. Create attributes for the user, such as 'Enboarder_Admin_Role', setting up different roles for different admin access levels

The below items highlight additional use cases to consider beyond the basic SSO setup process.

SSO when accessing content requiring authentication

When stakeholders access content that requires authentication (such as clicking the My Dashboard menu within content, when accessing a password-protected sequence or when completing form signature widget), they will have the option of using SSO instead of a pin and password if their account is set up with SSO.

Providing access to all stakeholders

In order to use SSO for stakeholder authentication, the below steps are required:

All employees should be given access to the Enboarder application in your SSO system. By doing this, all stakeholders will be able to use SSO.
For accounts that are configured with Just In Time provisioning, only Enboarder admin users should be given a role attribute that matches one of the roles defined like ‘Super Admin’, ‘General Admin’, etc.
For accounts that don't use Just In Time provisioning (where admins are created in Enboarder), the configuration will need to look like the below examples:

Microsoft AD

Okta

New Hires (or external employees) and SSO

New hires often don’t have corporate credentials yet. They access Enboarder via a link sent to their personal email address. Once they have their own corporate credentials (usually by day 1), then they can start using SSO to view their dashboard.

Multi-Tenant / Multi-IdP Support

Enboarder supports:

Multiple IdPs across subsidiaries
Parent-child account SSO inheritance

Each account can have:

Its own SSO configuration
Centralized or decentralized login control

To enable a parent account to authenticate sub-account admins, go to Settings > Security > Enable SSO for Sub-Accounts

SSO from a Parent and Child Enboarder account perspective

If you are using one global SSO system, and there are many accounts in Enboarder corresponding to aspects (brand, location, etc.), then you have two options.

1. One SSO configuration in the parent account

If you wish to configure SSO once and have this used across all of your accounts, then this is possible! Configure SSO as per above in the parent account. Once completed, after navigating to the Settings > Security section, tick the box to 'Authenticate sub-account admins with SSO from this page'.

Domains allowed for SSO in workflows

This setting allows you to set the domains that can utilise SSO when a stakeholder or employee is launched into a workflow and then navigates to their profile. Multiple domains can be entered in a comma-separated format and should be in lowercase only. If you leave this blank, this means that anyone can use SSO.

2. Multiple SSO instances for each account

Let's give the accounts names such as 'Enboarder Inc', 'Enboarder NA', 'Enboarder EU' and 'Enboarder APAC'.

The SSO setup is as usual, which was explained in the above steps, however, this time there will be 4 accounts in Enboarder, each account needs to have its own SSO settings showing in Enboarder.

The SSO admin of Enboarder Inc can setup SSO in their SSO system as we've run through above.

However, the SSO SP (Service Provider) ie. Enboarder's SSO details have to be unique for each of the 4 accounts.

You will need to setup 4 applications in your SSO system, e.g. 'Enboarder Central', 'Enboarder NA', 'Enboarder EU', 'Enboarder APAC'. To make these unique, you can leverage the Enboarder entity id suffix:

The SSO settings have to be completed in all 4 accounts in Enboarder.

The SSO IdP (Identity Provider) ie. account SSO's details will be unique for each of the 4 accounts.

Frequently Asked Questions

Can I restrict access by role/group?

Yes. Use group-based access or role-based attributes.

Can Enboarder support JIT (Just-In-Time) provisioning?

Yes, JIT provisioning is supported. If you do not wish to use this, then you can deactivate this in your SSO configuration settings in Enboarder. For full user provisioning, please refer to our SCIM API documentation.

Can users outside our corporate directory use Enboarder?

Yes:

Invite them manually
Add them to a limited-access group in your IdP

Can we configure SSO for UAT (User Acceptance Testing) and staging?

Yes. Each environment requires a separate SSO configuration and metadata.

What happens if the IdP is down?

Users cannot log in unless local login is separately enabled (rare).

Does Enboarder log SSO activity?

Yes. Contact support to access audit logs.

How is user deprovisioning handled?

Remove the user from their IdP group or role. Confirm they are deactivated in Enboarder. You can also leverage our SCIM API.

Can SSO and non-SSO users coexist?

Yes. Hybrid login models can be scoped with your Customer Success Manager (CSM).

What’s the session timeout policy?

Enboarder uses default session timeouts but may be configured to respect IdP policies.

Helpful Links

Enboarder Admin Roles & Permissions

Questions?

Reach out to the Support team by clicking the '?' button at the top right corner of any Enboarder page.

SSO (Single Sign-On) and Enboarder