Configuring Single Sign-On (SSO)

Learn how to configure your SmartSuite workspace for SSO to increase security and help your users be more efficient

Peter Novosel avatar
Written by Peter Novosel
Updated this week

Single Sign-on (SSO) is an authentication mechanism that facilitates a user logging into several independent software systems using a single ID and set of credentials. This is advantageous to organizations in several ways:

  • Mitigates risk because user passwords are not stored or managed externally

  • Reduces the time it takes for users to gain access to external resources

  • Lowers the number of IT password-related tickets

  • Reduces “password fatigue” where users adopt predictable password patterns due to the volume of passwords they need to manage

SmartSuite’s Workspace Administration interface facilitates the configuration of Single Sign-On for a workspace, in the Single Sign-On section of the Workspace Settings page. This article is intended to provide an overview of the available settings and options for this feature, and is intended for workspace administrators who are familiar with SSO and its implementation.

Important Notes

SSO is available only to SmartSuite Enterprise plan subscribers. If you are a SmartSuite Team or Professional plan subscriber and are interested in upgrading, you can contact us here for more information.

If a Workspace Admin enables SSO for Workspaces containing Solutions 1, 2, and 3, the Admin cannot optionally remove the SSO gate for Solution 1 but leave it on for 2 and 3.

Before You Begin

Prior to configuring SSO in your SmartSuite workspace, you will need information about your SSO provider.

  • Email domain. You will be required to provide the email domain associated with your Single Sign-on process.

  • Protocol. SmartSuite currently supports the OpenID Connect and SAML protocols for SSO. If your organization requires a different protocol, please contact us here.

Single Sign-On with OpenID Connect Prerequisites

Configuration of OpenID Connect SSO requires the following information:

  • Issuer URL

  • Client ID

  • Callback URL (Read-Only)

Single Sign-On with SAML Prerequisites

Configuring SSO with SAML requires the following information:

  • Sign in URL

  • X509 Signing Certificate (you will attach it via File Upload)

  • Sign Out URL (optional)

  • User ID Attribute

  • Whether you need a signed request

    • Sign Request Algorithm (one of the following)

      • RSA-SHA256

      • SHA1

    • Sign Request Algorithm Digest (one of the following)

      • SHA256

      • SHA1

  • Protocol Binding (one of the following)

    • HTTP-Redirect

    • HTTP-Post

SSO Configuration Process

After retrieving your organization's OpenID or SAML SSO metadata, navigate to the Workspace Administration interface from the user profile menu, then click on the Single Sign-On link in the left navigation menu or the Workspace Settings tab.

The Manage Single Sign-On dialog will be displayed. First specify the email domain associated with your Single Sign-On provider. Next, select whether you want to use OpenID or SAML to communicate with your provider.

The next steps will require the use of the SSO metadata you collected prior to starting configuration (see the beginning of this article if you skipped that). The exact steps differ depending on protocol.

OpenID Connect Configuration

Follow these steps to configure OpenID Connect:

  1. Enter the provider’s Issue URL

  2. Specify the provider’s Client ID

  3. Cut and paste the Callback URL for the provider

  4. Click Save Configuration

The interface looks like this:

If configuration is successful, you should see the Single Sign-On pane in workspace settings with an Enabled indicator, like this:

SAML Configuration

Follow these steps to configure SAML:

  1. Provide the Sign in URL

  2. Upload your SAML X509 Signing Certificate

  3. Specify whether you want to Enable Sign Out

    1. If you do, you will be prompted to enter a redirect URL

  4. Enter the User ID attribute

  5. Specify whether you want to Sign Requests

    1. If you do, you will have to specify the algorithm for the request and the request digest (SHA256 or SHA1)

  6. Select the Protocol Binding that your provider requires, one of the following:

    1. HTTP-Redirect

    2. HTTP-POST

  7. Click Save Configuration

The configuration UI looks like this:

You can always click Edit if your Single Sign-On configuration needs to be modified in the future.

Single Sign-On Tips

  • We only support one email domain per SmartSuite workspace.

  • Changes may take up to 5 minutes to take effect.

  • Users must still be invited by a SmartSuite administrator before they will be able to log in with SSO.


Here are a list of frequently-asked questions about SmartSuite's SSO capabilities:

Q. Does SmartSuite SSO work with Shibboleth?

A. Shibboleth supports SAML, which is one of two protocols SmartSuite supports (the other is OpenID Connect, which Shibboleth does not support).

Q. Can administrators (e.g. department staff) login using SSO?

A. Yes, administrators are permitted to log in using SSO.

Q. When a user logs out, is SmartSuite able to redirect the user to SSO IdP logout URL?

A. Yes, a sign out URL can be specified.

Q. When configuring SAML SSO, what attributes are required?

A. The following attributes can be configured:

  • Protocol (SAML)

  • Sign in URL

  • X509 Signing Certificate

  • Service Provider Entity ID

  • Assertion Consumer Service URL

  • Sign out URL (optional)

  • User ID Attribute

  • User Email Attribute

  • Sign Request Algorithm (optional)

  • Sign Request Algorithm Digest (optional)

  • Protocol Binding (HTTP-Redirect or HTTP-POST)

Q. What is the key identifier SmartSuite uses for SSO?

A. SmartSuite uses email as the key identifier

Q. Will SSO data (e.g. name, email, etc.) be accessed by SmartSuite staff?

A. No, SmartSuite staff will not access this data,

Q. How do we provision and de-provision access to target population or department staff?

A. SmartSuite does not yet support automated provisioning / de-provisioning. A SmartSuite user with the Administrator role must invite the user, and similarly must inactivate or delete a user to de-provision. The Invite and inactivation/deletion actions can be performed via SmartSuite’s REST API.

Q. Is API integration supported? For example, can the vendor make an API call to get the target population?

A. A list of users can be retrieved via SmartSuite’s REST API.

Q. Please describe the storage environment and how data will be protected.

A. All internal data is transiting only through internal AWS VPC without any connection to the Internet. All external data has SSL encryption with latest AWS SSL security policies. All data at rest encrypted with AWS KMS keys generated for our account. Endpoints of our application are secured with AWS WAF protection.

Q. Where is SmartSuite hosted?

A. SmartSuite services currently run in Amazon Web Services (AWS) US-East2 data center.

Did this answer your question?