Authorization and Access Control Using SAML

Instruction and methodology for defining your access policy and managing SAML for your organization.

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 account

• Determine if existing users need to be migrated

New Sites

• 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.

Ensure that you test access with users.

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

Control Modes

Tulip Control Mode is the current behavior where a user's Tulip role and workspace is taken from the SAML attribute mapping only the first time they log in to Tulip. Users deactivated in Tulip are prevented from logging in.
IdP Control Mode means that whenever a user successfully authenticates, they will be reactivated. Their Tulip role and workspace will update from the IdP.

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

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.

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.

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 sites 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

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 is:

tulip-globalViewer

Did you find what you were looking for?

You can also head to community.tulip.co to post your question or see if others have faced a similar question!