Single Sign-On (SSO) for Tempo Manufacturing Cloud
Overview
Single Sign-On (SSO) allows your organization to authenticate users into Tempo using your existing corporate identity provider (IdP). Once enabled, users sign in with their company credentials instead of a Tempo-specific username and password.
Tempo supports SAML 2.0–based SSO.
This article explains:
- What SSO changes for users and administrators
- What information your IT team needs to configure SSO accurately
- How SSO interacts with Multi-Factor Authentication (MFA)
- How to verify and troubleshoot your setup
This article is intended for a mixed audience: customer IT/identity administrators and Tempo end users. Technical details required for correct setup are included, but internal-only processes are intentionally excluded.
How SSO Works in Tempo
Understanding Groups and Permissions
In Tempo, a group represents a set of permissions. Users must belong to at least one group to meaningfully interact with the system.
A user with no group membership may be able to sign in successfully; however, without a group, the user may be unable to access features or perform actions.
During SSO login, Tempo enforces group membership through the following behavior:
If group information is included in the SAML assertion, Tempo assigns the user to the corresponding groups provided by the Identity Provider.
If no groups are provided in the SAML assertion and the user has no existing active group memberships in Tempo, Tempo assigns the default Migrated Role group as a fallback.
This fallback authorization behavior prevents scenarios where users can authenticate successfully but are effectively blocked from using the system due to missing permissions.
High-Level SSO Login Flow
At a high level, the SSO login process follows this sequence:
- Tempo validates whether the user already exists.
- Tempo determines whether auto user creation is enabled.
- Tempo evaluates whether group information is included in the SAML assertion.
- Tempo assigns access based on IdP-provided groups, existing Tempo groups, or the default group as a fallback.
Understanding this flow is important when troubleshooting login or authorization issues, especially in environments that evolved from older Tempo versions.
When SSO is enabled:
- Tempo becomes a Service Provider (SP)
- Your corporate authentication system becomes the Identity Provider (IdP)
- Authentication is handled by your IdP and asserted to Tempo using SAML
After SSO is active:
- Existing Tempo passwords are no longer used
- Users authenticate through the IdP when signing in
- The same SSO login applies across supported Tempo solutions (for example, Tempo Manufacturing Cloud web app and supported mobile apps)
What Changes for End Users Logging in with SSO
Once SSO is enabled for your organization:
- Users navigate to your organization’s Tempo web application URL.
- Users enter their email address.
- Tempo redirects the user to the organization’s corporate login page.
- After successful authentication, the user is redirected back into Tempo.
If your organization enforces MFA (multi-factor authentication) at the IdP level, users will complete MFA as part of the corporate login experience.
Logging out
Users log out of Tempo from the left navigation panel. Logout behavior after that point is controlled by the IdP session configuration.
MFA and SSO
When MFA Is Managed by Your IdP
- When SSO is enabled, MFA should be managed by your IdP, not Tempo.
- Tempo will rely entirely on the authentication (and MFA) result asserted by your IdP.
Conditional Access (Example: Microsoft Entra)
Organizations using Microsoft Entra ID (Azure AD) may choose to:
- Enforce MFA globally
- Bypass MFA for Tempo from trusted networks
- Apply app-specific MFA policies
These behaviors are configured entirely within the IdP using Conditional Access policies. Tempo does not control or override IdP MFA policies.
SSO Identifier (NameID) Requirements
Tempo initiates SSO using the user’s email address. For SSO to complete successfully, the Unique User Identifier (SAML email) returned by the Identity Provider must match that email.
**
Required Configuration
SAML NameID / Unique User Identifier: user.mail
Some Identity Providers allow users to authenticate using a non-email identifier (such as employee ID, username, or UUID). This is supported only if the SAML assertion still returns the user’s email address as the NameID.
Unsupported or Risky Configurations
Do not use the following as the SAML NameID:
- user.userprincipalname (UPN values may not match the user’s email)
- Internal system IDs or UUIDs
- Any identifier that does not exactly match the email entered on the Tempo login screen
If the identifier returned by the IdP does not match the email used to initiate login in Tempo, authentication may succeed at the IdP but fail when Tempo processes the response.
What Your IT Team Configures
Your IT or identity team is responsible for configuring a new SAML application (Service Provider) in your IdP using information provided by Tempo.
SAML Configuration Overview
At a high level, your IdP configuration will require:
- Entity ID (provided by Tempo)
- Assertion Consumer Service (ACS) / Entry Point URL
- Single Logout URL (if supported by your IdP)
- X.509 Certificate used to sign assertions
Tempo provides these values through its SAML metadata XML after initial SSO setup.
Entity ID
- Typically based on your Tempo vanity URL
Example formats may include a short identifier or a URL-style Entity ID
Any non-standard Entity ID should be agreed upon before finalizing setup
Entry Point (ACS URL)
- This is the endpoint where your IdP sends SAML assertions after authentication
- The exact value is provided in the Tempo SAML metadata
Certificate
- Your IdP will sign SAML assertions using an X.509 certificate
- This certificate must be shared with Tempo so it can validate incoming assertions
Initial Setup and Final Synchronization
SSO setup typically happens in two phases:
- Initial configuration
- SSO is enabled in Tempo
- Placeholder values may be used temporarily
- Tempo SAML metadata becomes available
- Final synchronization
- The customer configures the IdP using Tempo metadata
- Tempo is updated with the IdP’s final Entry Point, Logout URL, and certificate
- This sequencing ensures both systems are aligned before users begin authenticating.
Detailed SSO Login and Authorization Behavior
The following describes how Tempo processes an SSO login request once authentication is completed by the Identity Provider.
Step 1: User Existence Check
- If the user already exists in Tempo, login proceeds.
- If the user does not exist:
- If Auto User Creation is enabled, the user is created.
- If Auto User Creation is disabled, login fails.
Step 2: Group Assignment/Evaluation
After the user exists (either pre-existing or newly created), Tempo evaluates group information.
When the SAML Assertion Includes Groups
- Tempo assigns permissions based on the groups asserted by the IdP.
- Migrated Role Groups are not created or used in this path.
When the SAML Assertion Does Not Include Groups
- Tempo checks for existing group assignments within Tempo.
- If matching groups are found, those groups are used.
- If no matching groups are found:
- Tempo assigns Migrated Role Groups to preserve legacy permissions.
- These migrated groups represent permission sets carried forward from earlier role models.
Resulting Behavior
For Tempo versions 7.7.001 and higher, Migrated Role Groups appear only if both of the following checks fail:
- No groups are sent via SSO (the SAML assertion does not include group information)
- The user has no group assignments in Tempo
If either of these checks passes:
- Group information is provided by the IdP or
- The user is already a member of one or more groups in Tempo
then Migrated Role Groups are not created or used.
This ensures that migrated roles are only applied as a fallback mechanism when no group-based authorization data is available from either the IdP or Tempo.
Removing migrated groups breaks the authorization path only in scenarios where both checks fail and migrated roles are required for access continuity.
Optional: SSO Email Domains
Tempo supports configuring one or more SSO Email Domains.
When configured:
- Users who enter an email address matching the domain are automatically redirected to SSO
- This is commonly used with auto user creation scenarios
SSO Email Domains are optional and should be configured only after SSO is functioning correctly.
User Creation Behavior
Depending on your configuration:
- Auto user creation enabled: New users authenticated via SSO are automatically created in Tempo
- Auto user creation disabled: Only existing Tempo users can log in via SSO
Version-Specific Behavior Notes
Why Default (Migrated Role) Groups Exist
Earlier versions of Tempo allowed users to exist without any group assignment. This resulted in scenarios where authentication succeeded but the user was unable to do anything in the system until an administrator manually assigned a group.
To prevent this "login works, but user is blocked" scenario, Tempo introduced a default fallback group (commonly referred to as a Migrated Role group) during SSO login when no group information is available.
Legacy Behavior: (Versions 7.6.000 through 7.6.007 and 7.7.000)
In Tempo versions 7.6.000 through 7.6.007 and 7.7.000, when no groups were sent via the SSO Identity Provider, Tempo automatically assigned the default Migrated Role group on every login. This occurred regardless of any manual group assignments.
This behavior could result in unexpected or confusing group assignments when reviewing user access.
Current Behavior: (Versions >=7.6.008 and >=7.7.001)
From versions >=7.6.008 and >=7.7.001, The default group is assigned only when no SAML groups are provided and the user has no existing group assignments. If the user already has at least one group, the default group is not reapplied.
Avoiding Default (Migrated) Groups
To avoid reliance on default migrated roles, use one of the following approaches:
-
Option 1 (Recommended): Manage Groups in the Identity Provider
- Configure your IdP to send group names in the SAML assertion
- Ensure group names match Tempo group names exactly (including capitalization)
- Tempo will assign permissions based on IdP-provided groups
-
Option 2: Manage Groups Directly in Tempo
- Disable automatic user creation for SSO
- Have an administrator create the user and assign at least one group before first login
These options provide predictable authorization behavior and reduce dependency on fallback group logic.
Support Callout: Users Can Log In but Cannot Do Anything
Symptom: A user can successfully log in via SSO but cannot access features or perform actions in Tempo.
Most common causes:
- The user is not assigned to any group that grants permissions
- The SSO IdP is not sending group information and fallback groups are missing or removed
What to check:
- Confirm the user belongs to at least one group in Tempo or receives group assignments from the IdP
- Verify whether default group (migrated roles) still exists if your environment relies on fallback behavior
- Confirm your Tempo version and review version-specific behavior notes below
Tip: Authentication success does not guarantee authorization. Group membership controls what a user can do after login.
One-Page SSO Authorization Decision Table
Verifying Your SSO Setup
After configuration is complete, your organization should verify:
- Existing users can successfully log in using SSO
- MFA behavior matches expectations based on IdP policy
- (If enabled) new users are created correctly after first SSO login
- Users without access in the IdP cannot log in
Testing from both trusted and non-trusted networks is recommended if Conditional Access policies are in place.
Important Warning: Migrated Role Groups
⚠️ ⚠️ Do not delete Migrated Role Groups.
Migrated Role Groups exist to preserve access for users who were originally created under earlier Tempo versions, when a smaller set of roles was available.
As Tempo roles and permissions evolved, existing users were migrated to newer roles, while their original permission sets were retained in Migrated Role Groups to ensure continuity of access. These migrated groups remain part of the authorization model for those users.
Deleting Migrated Role Groups can prevent users from completing login via SSO, even when SAML authentication succeeds at the Identity Provider. This is because required permission mappings may no longer be available after authentication.
Important caveat: Migrated Role Groups are not used when your Identity Provider (IdP) is configured to send group names as part of the SAML assertion. In group-based SSO configurations, Tempo maps access directly from IdP-provided groups instead of migrated role groups.
Guidance for managing access:
- If your IdP does not send groups: do not delete Migrated Role Groups; adjust access by modifying user assignments or permissions instead
- If your IdP does send groups: manage access through IdP group membership
If Migrated Role Groups were deleted and users can no longer log in, contact support with details of the change so access can be restored.
Troubleshooting Tips
- Confirm users are accessing the correct Tempo organization URL
- Verify the Entity ID in Tempo matches the IdP configuration exactly
- Ensure the certificate configured in Tempo matches the active IdP signing certificate
- If authentication succeeds but login fails, review SAML assertion attributes and NameID format
If issues persist, collect the SAML metadata and error details from your IdP before contacting support.