Applies to
- Enterprise
Capabilities
Who can use this capability
- System Admin
Configure SAML for domain-level single sign-on to Smartsheet
The SAML configuration at the domain level allows you to implement a unified single sign-on (SSO) for your domain across plans.
Who can use this?
Plans:
- Enterprise
Permissions:
- System Admin
Find out if this capability is included in Smartsheet Regions or Smartsheet Gov.
You need an IT Administrator to set up SAML for SSO with Smartsheet.
By enabling the SAML configuration at the domain level, you ensure a consistent SSO experience across various plans within a verified and activated domain. It also guarantees a uniform process for all users belonging to that domain, regardless of their department or the specific Smartsheet plan you’ve assigned to them.
This feature is Enterprise-only. Once configured by the System Admin, the policy applies to any Smartsheet user in that domain, regardless of their plan type.
Note that your existing plan-level SAML configurations remain functional for users belonging to that domain. However, you now have the option to implement domain-level SAML. Once you activate domain-level SAML, it overrides your previous plan-level SAML for users in that domain.
Prerequisites
- Verify and activate your domains through the Domain Management screen before setting up a domain-level SAML configuration. Learn how to activate a domain.
Activate the Smartsheet V2 application in Okta.
This requirement is for the Okta-based SAML configuration only.
Set up SAML in your IdP and get SAML attributes to be updated in Smartsheet during the SAML configuration.
SAML attribute requirements
The following attributes are required in Smartsheet for the SAML exchange process:
- Persistent ID: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- Email address: email
- (Optional, but recommended):
- Given name: givenName
- Surname: surname
Some SAML services may ask for additional information, such as the Assertion Consumer Service (ACS) URL and the Audience Restriction (Entity ID). You can easily find these values on the Configure SAML IdP screen.
To access the screen:
- Go to Admin Center
- Navigate to Authentication and select Add a SAML IdP > Other IdP (Customize)
In Azure, you don't need to manually enter the persistent ID value, as it's automatically included through the Unique User Identifier claim that comes pre-filled. For the Unique Identifier Claim, the value passed must be user.userprincipalname. The only attribute value you must add manually is the email address. Any other pre-populated claims within the application should be deleted. Learn more about configuring Azure for domain-level single sign-on to Smartsheet.
Set up SAML for single sign-on to Smartsheet
- Go to the Admin Center and select the menu icon.
- Navigate to the Settings tab and select Authentication.
- Select Add a SAML IdP.
- Select Configure on either of the following:
Okta-based SAML configuration
- Enter a name for your Okta SAML configuration in the Name Okta IdP field.
Copy the values from the Assertion Consumer Service (ACS) URL and Audience Restriction (Entity ID) fields, and paste them into the ACS URL and Audience URI fields in the Smartsheet v2 Okta app, respectively. You’ll do this to establish Smartsheet as a service provider, allowing you to get SAML metadata from your Okta instance.
Brandfolder Image
- Follow the instructions on the screen to get the Okta metadata URL and then select Save & Next.
- You're now required to test your connection by signing in to Smartsheet using Okta. Select Verify connection.
- After verifying your connection, select the I have successfully verified the connection checkbox.
Select Save & Next.
Brandfolder Image
- Assign your active domains to Okta using the drop-down field or select Add domain to find any domains you wish to add.
Select Save & Next.
Brandfolder Image
- Follow the instructions on the screen to create an Okta bookmark app to allow your users to sign into Smartsheet from their Okta app home.
- Select the checkbox to confirm you've successfully created an Okta bookmark app for Smartsheet.
Select Finish.
Brandfolder Image
Custom SAML configuration
Follow the instructions on the screen to establish Smartsheet as a relying party and then select Next
Brandfolder Image
- Enter a name for your custom SAML configuration in the Name SAML IdP field.
Import your SAML IdP metadata from either an XML file or a public URL that hosts an XML file from your identity provider.
The XML URL option is the recommended method for importing your metadata.
Select Save & Next.
Brandfolder Image
- You're now required to test your connection by signing in to Smartsheet using your custom SAML IdP. Select Verify connection.
- After verifying your connection, select the I have successfully verified the connection checkbox.
Select Save & Next.
Brandfolder Image
- Assign your active domains to your custom SAML IdP using the drop-down field or select Add domain to find any domains you wish to add.
Select Finish.
Brandfolder Image
You can't turn on your new SAML configuration without first verifying your SAML IdP connection.
About current plan-level SAML configurations
- Those without a plan-level SAML setup or new to Smartsheet only have the option to configure SAML at the domain-level. However, if you still require plan-level SAML, you should reach out to Smartsheet support or your Smartsheet contact.
- Current plan-level or domain-level SAML configurations remain functional for users belonging to a domain until the Smartsheet SAML certificate expires. Learn more about certificates expiry.
- The Admin Center will display a warning message informing of the number of days left before your current plan-level SAML configurations expire.
- In instances where both plan-level and domain-level SAML configurations exist, domain-level configuration takes precedence and replaces any existing plan-level setup for users within that domain.
- If a plan currently offers login methods such as email/password, Google SSO, or SAML, and an Enterprise plan sets up domain-level SAML for a particular domain, users from that domain will continue to see the same login options. Additionally, they'll also have access to the newly configured domain-level SAML, regardless of their plan type.
Keep this in mind
The Enterprise plan that validated and activated the domain is the only one capable of configuring and applying domain-level SAML settings, affecting all users within that domain.
However, if other Enterprise plans have validated the same domain, they also have the ability to configure a draft domain-level SAML configuration. Nevertheless, they won't be able to apply the settings since they weren't the ones who activated the domain.
Can I use Google SSO or Azure SSO with the domain-level SAML configuration?
Initially, only SAML will be available for the domain-level configuration. We’ll allow the domain-level Google SSO/Azure SSO login policy set-up at a later date.
What should I do if I experience issues during the transition to domain-level SAML?
Contact Smartsheet Support for assistance if you encounter problems during the transition.
How can I revert back to plan-level SSO settings if needed?
After transitioning to domain-level SAML configuration, reverting to plan-level SSO settings isn’t possible. Ensure you’re prepared for this change before implementation.
Are there any additional costs involved in moving to domain-level SAML configuration?
No. There aren’t additional costs for enabling domain-level SAML configuration; it's included in your existing Smartsheet Enterprise plan.
Can I have different SAML configurations for different domains?
Yes. You can configure different SAML settings for each validated and activated domain. This flexibility allows for tailored security settings across various segments of your plan.
How will this change affect my current users' login experience?
Once domain-level SAML is configured for a validated and activated domain by a System Admin on an Enterprise plan, all users belonging to that domain, regardless of their plan type, will be subjected to the prescribed SAML login method. However, all other plan-level configurations (like Google SSO, Azure SSO, email and password, etc.) will still be available to end users belonging to that plan.
What happens to existing user sessions when the domain-level SAML configuration is activated?
Existing sessions should remain unaffected. However, once a user logs out, they’ll need to log back in using the new domain-level SAML configuration.
Can I roll out the domain-level SAML configuration in phases across my plan?
The configuration is applied at the domain level, so it's more suited for a full-scale rollout rather than a phased approach.
Can I enable domain-level SAML configuration on multiple Enterprise plans?
Only the Enterprise plan that has validated and activated the domain can configure the domain-SAML policy for all users and plans belonging to that domain.
Can I set up a user movement policy while leveraging domain-level SAML?
No. The user movement policy is incompatible with domain-level SAML configurations.