SAML allows organizations to manage authentication and access rights of Tulip users using their existing identity provider (IdP). This guide will detail the process of discovery and implementation of Enterprise level SAML installation. For a single site, please consult our support article here.

High-level process

Prework

Understand Tulip user roles

Bucket employees into role based groups

Identify who within your organization will configure your IdP, and Tulip

Determine if existing users need to be migrated

For every new site

Tulip Enables SAML on your site

Your organization configures SAML (both in your IdP and in Tulip) and grants users access

New site creation process

Send a request to your Tulip Customer Success Manager that you would like to create a new site with SAML. You should provide the following:

  • Site name and URL

  • The name and email of the person from your organization who will log in and configure SAML

Tulip will create the site and enable SAML

The person responsible for configuration will receive an email to log into the site, they will configure SAML as described here. They will configure the site based on your access strategy, the two of which are defined below.

Test access with users

Note:

Once complete, the Account Owner needs to delete the user account of the person who configured SAML as their account uses a Tulip username and password. If that person will be maintaining SAML for the future, they should be given Account Owner access and sign in with SAML for future configurations.

Tulip created SAML certificates expire yearly. Tulip will reach out to notify your team 2 weeks in advance to rotate the certificate.

Active site SAML conversion process

Same as above, but before SAML is enabled, we will need to convert all existing users from Tulip accounts to SAML accounts. For this, we need a list of every user's email and their IdP provided NameId. We will work with the person responsible for configuration to make that conversion with minimal downtime. If existing users are not needed we can simply delete all users. Keep in mind that existing data such as completions linked to those users will not be migrated to their new user. See documentation here

References

Step-by-step instructions for configuring Tulip for Azure Active Directory are here.

Configuring Access

LTS 6

With the release of Workspaces in LTS 6, SAML Authorization strategy has changed to better allow organizations to manage their users without creating an unnecessary burden on IT.

SAML Changes

There are now two options for authorization:

SAML Custom Role Mapping

On the first login, a user is assigned a role based on the groups presented in their role attribute. After that point, Tulip will no longer read the role attribute of that user, and any role changes must be done in the platform by an account owner.

If this method is chosen, you will need to request that your IdP team add the appropriate role to all users that require Tulip access.

Default Role Mapping

On the first login, all users are given a default level of access (Viewer with Player access), the account owner will then need to adjust the role to the appropriate level.

Access Control

You can choose to add an access control attribute, where the user needs to have a specific value in order to access Tulip. This is especially relevant for default mapping scenarios, where you still want to dictate who should be able to access Tulip, regardless of role or workspace.

For example:

  • A user must have an attribute TulipAccessControl set to True

  • A user must belong to a group TulipUsers, which is exposed through an attribute TulipAccessControl (See example below)

If you choose to use Access Control, you will need to request that your IdP team adds the defined attribute and value to all users who should have any access to Tulip

Workspaces

You can read about workspaces in detail here <link>

Like the role attribute, you will now be given the option to map users to workspaces.

SAML Custom Workspace Mapping

On the first login, a user is assigned workspace access based on the groups presented in their workspace attribute. After that point, Tulip will no longer read the workspace attribute of that user, and any workspace changes must be done in the platform by an account owner.

If this method is chosen, you will need to request that your IdP team add the appropriate workspace to all users that require Tulip access.

Default Workspace Mapping

On the first login, all users are given access to a default workspace of your choosing. An account owner can then adjust workspace access.


Creating Access Groups

For custom role mapping option (Default Pre LTS 6)

Creating standardized Tulip access groups:

Every user will need a role attribute specified in your IdP that Tulip uses to determine their privileges once they’ve authenticated with their IdP username and password. We can also use this Role field to determine what sites they have access to using a standard naming convention. While a role field can just be a set variable, it is recommended that you assign the user to Tulip specific groups and map those to an attribute.

Role

Review the Tulip access roles here. Every user will need at least one role. If a user has multiple roles, Tulip will select the one with the highest access.

An example role is Account Owner.

Note: There needs to be at least one Account Owner per site

Site

Let’s say your organization has two sites, with a Tulip instance for each.

We can denote each site by its location (texas, and london respectively).

Combining the two

We can combine these two things to create a group matrix for users to be assigned. We recommend that organizations append or prepend the value with Tulip, so it’s easier to filter by.

Convention: tulip-siteRole

acme-texas.tulip.co

acme-london.tulip.co

Account Owner

tulip-texasAccountOwner

tulip-londonAccountOwner

Application Supervisor

tulip-texasApplicationSupervisor

tulip-londonApplicationSupervisor

Viewer

tulip-texasViewer

tulip-londonViewer

Operator

tulip-texasOperator

tulip-londonOperator

...

If Jane Smith is the site lead at the Texas site, we would assign her to the group tulip-texasAccountOwner. If Jane Smith also needs view access into the London site, she could be added to the group, tulip-londonViewer.

Exposing these groups as an attribute for Tulip

In your IdP, Jane should have an attribute, tulip-role, where any groups she is a member of that contain the prefix “tulip-” will be mapped. When she signs into Tulip, the attribute tulip-role has two values: tulip-texasAccountOwner, tulip-londonViewer.

Global Roles

You may also want to create global access roles, as a viewer for example. The format for that would be

tulip-globalViewer

Note: If a user who is a member of the global viewer group logs into a site where they also have a role with more access, Tulip will give them the highest access available.

Did this answer your question?