Enterprise Authentication

The core use of enterprise authentication is to integrate with an existing identity provider (IdP) and provide an authentication service for users logging into Tulip and the Tulip Player.

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. The Identity Provider stores or federates information about users and what applications they have access to.

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

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

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

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

Creating Standardized 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. The role field can also be used to determine what sites they have access to using a standard naming convention.

While a role field can be mapped using existing group information, it is recommended that you assign the user to Tulip-specific groups and map those to an attribute.

Every user will need at least one role. If a user has multiple roles, Tulip will select the role with the highest level of access. A user can also have multiple roles for different sites.

At least one Account Owner must exist per site.

Identity Provider Configuration

Within the Account Settings page of the Tulip instance, the identity provider configuration details will need to be provided. You can opt to upload your IdP metadata XML to fill in these fields, but ultimately an SSO login and logout URL is needed, as well as the certificates for your IdP server to verify SAML responses. The certificates must be in PEM format.

Tulip's SAML SP certificates expire yearly. Tulip will reach out and notify customers two weeks prior to expiration to rotate the certificates.

Attribute Mapping

Once the IdP attributes have been configured, they can be mapped within Tulip. Three attributes are required: Name, Email, and Badge.

Role Mapping

There are two options for role mapping in Tulip: Tulip Default Role Mapping and Custom Role Mapping.

Tulip Default Role Mapping

On first login, all users are given a default level of access (Viewer with Player Access). The Account Owner must then adjust the roles of users to appropriate levels. The roles within Tulip will govern access from that point forward.

Custom Role Mapping

On first login, all users are assigned a role based on their IdP Role attribute. This is only for initial configuration - once a user has authenticated, Tulip will not directly read the Role attribute of the user again. Therefore, any role changes must be done within the platform by an Account Owner.

To configure custom roles, the naming convention used for the values within the Role attribute should be mapped to a standard Tulip role to be granted to the user. Each attribute value must be mapped to at most one Tulip role, but a given Tulip role may be mapped from more than one attribute value.

Access Control

Access Attribute

If a user does not have this SAML attribute, they will not be allowed to log in to Tulip. If left blank, any user in your organization will be allowed to log in to Tulip (as long as they have a role).

Access Value

If a user does not have the access attribute set to this value, they will not be allowed to log in to Tulip. If left blank, users may have any value in the attribute.

This is relevant for default mapping scenarios, where the userbase still needs definition of who can access Tulip, regardless of role or workspace.

Customization

The label on the login button for Tulip login pages can be customized. The default value is "SAML".

Workspaces Mapping

With Workspaces enabled, an additional set of attributes and mappings become available for access control. The two same options for mapping are present.

Tulip Default Workspace Mapping

On first login, all users are given access to a configurable default workspace. An Account Owner can then adjust Workspace access.

Custom Workspace Mapping

On first login, a user is assigned workspace access based on a defined Workspace attribute. Once a user has authenticated, Tulip will not directly read the Workspace attribute of the user again. Therefore, any workspace changes must be done within the platform by an Account Owner.

To configure custom Workspace mappings, the naming convention used for the values within the Workspace attribute should be mapped to a standard Tulip Workspace to be granted to the user. Each attribute value must have a unique mapping, but more than one Workspace may be mapped from a given attribute value.

Any Workspaces that do not have a mapping will not be accessible.

Automatic Log Out

Tulip supports IdP-initiated logout. 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.

Login Throttling

Login access will be disabled for approximately 10 minutes after 10 failed attempts.

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, including SAML usernames, a Tulip user must use the Record History Widget within the Tulip Player.

Requirements