Enterprise Authentication

The core use of LDAP and SAML is to integrate with an existing user administration system (e.g. Active Directory), and to provide an authentication service for users logging into Tulip and the Tulip Player.

Without LDAP and SAML, users with "operator" roles log in through badge IDs as opposed to LDAP or SAML username and password. Turning on the LDAP or SAML integration provides a greater level of security.

To learn more about the available roles in Tulip, see this guide to User Roles.

There are two ways to integrate LDAP and SAML with Tulip:

1. Tulip Control Mode - A Tulip instance uses LDAP or SAML for authentication verification only. User records must also exist in Tulip for a user to log in, and user roles are defined in Tulip.

2. LDAP/SAML Control Mode - A Tulip instance uses LDAP or SAML for both role assignment and authentication. If a user passes the LDAP or SAML authentication step, they will always be able to login into Tulip according to their role defined in LDAP or SAML.

This configuration is set up by a Tulip employee initially. It becomes a fixed and standard part of the customer's individual deployment of Tulip software. The Tulip instance's deployment configuration determines whether to use LDAP or SAML and which mode to use.

A Tulip employee must configure the customer's Tulip account to use LDAP. The Tulip employee can also optionally specify LDAP group names to determine user privileges in Tulip, which means that the instance will be in LDAP control mode. If these groups are not specified, the instance is in Tulip Control Mode.

If a Tulip employee navigates to a customer's directory and runs the SAML setup script, the instance will be able to use SAML authentication after a Tulip employee enables the SAML enablement feature flag and the customer configures their SAML setup within Account Settings.

Tulip Control Mode

Besides using LDAP or SAML for authentication, the primary experience for creating and managing users and operators is largely the same as using Tulip without an LDAP or SAML integration. For a description of creating users, see this guide to the Users page or this guide to the properties of each individual user.

Optionally, a Tulip employee can configure the customer's account so that operators are allowed to log in via badge IDs by turning "on" a feature flag. This means that operators will not be tied to the customer's LDAP or SAML account.

LDAP Control Mode and LDAP overview

LDAP is a specification for storing and searching databases. It's commonly used for storing organizational and authentication data. By traversing the parent-child linking of nodes one can generate a DN (Distinguished Name) in the LDAP hierarchy. Nodes in the LDAP tree are named via a left-to-right syntax. For instance this DN:

“cn=group1,cn=Users,dc=tulip,dc=co”

refers to a node called group1, whose parent is Users, whose parent is tulip, whose parent is co. A sample Tulip server configuration for setting up LDAP Control Mode might look like this:

{
  "ldap.userGroupDN.admin": "cn=group1,cn=Users,dc=tulipintra,dc=net",
  "ldap.userGroupDN.operator": "cn=group2,cn=Users,dc=tulipintra,dc=net",
}

In this case users assigned to Users\group1 in tulipintra.net in LDAP would be users, and users assigned to Users\group2 in tulipintra.net in LDAP would be operators.

In the Tulip platform, operator login and user login are two different code paths, and the appropriate LDAP check is done on the corresponding login. If a user logs in for the first time, a new Tulip record is made that corresponds to that operator or user login.

One caveat to this approach is that a user that has both operator and user access defined in LDAP might show up as an operator in Tulip if they have not also logged into Tulip. Once they log into Tulip, their profile will be updated to show they are a user.

Bioauthentication using Nymi Bands

If an account uses LDAP for authenticating users and NOT operators, then the account can use Nymi Bands for bioauthentication of operators. This means that operators can only sign into the Tulip Player while using a Nymi Band.

In order to configure this integration, a Tulip team member must prepare the instance to only allow bioauthentication for operators.

SAML Control Mode and SAML overview

Tulip integrates with your existing SAML provider and allows you to use SAML login/logout in different parts of the platform.

This integration allows Tulip users to log in to Tulip the same way they log in to other systems in your organization.

SAML is a generic authentication protocol supported by a wide range of systems. In SAML terminology, Tulip is a Service Provider (SP), and your SAML software is the Identity Provider (IdP). The Identity Provider stores or federates information about users and what applications they have access to.

Tulip acts as one of those applications. It can use the SAML protocol to request information about users from the IdP when they log in.

Tulip adheres to the SAML 2.0 specification.

Your identity provider must support the ForceAuthn argument from the SAML 2.0 specification.

Role Mapping Between SAML and Tulip

A user with the "Account Owner" role in Tulip must specify the SAML attribute that will determine the user's role in Tulip when they log in.

Then, they must specify individual values of this SAML attribute and which Tulip roles these values should be mapped to.

Automatic Log Out

Tulip supports IdP-initiated logout. So, if you want users to log out of all software services at once via a logout from your identity provider, Tulip will respond to that logout request.

History Records

In Tulip, common manufacturing assets such as batches, materials and assemblies are tracked as records in the Tables feature.

To view the full history of any of these records, a Tulip user must use the Record History Widget within the Tulip Player.

Requirements