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.
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
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
Step-by-step instructions for configuring Tulip for Azure Active Directory are here.
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.
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.
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.
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
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.
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
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.
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.
You may also want to create global access roles, as a viewer for example. The format for that would be
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.