Single Sign-On (SSO) Administrator’s Overview

Single Sign-On (SSO) is used by organizations to centrally control access to applications and services. Please note that SSO integration in Shotgun is not trivial. An important part of the work is required at the Identity Provider (IdP) level. As a Shotgun Admin, you will need to discuss with your IdP Administrators to ensure that the required information is sent over, and in the proper format.

To use SSO, you must first submit a Support Ticket asking for an onboarding session with our Street team. Please ensure that you meet all of the requirements.


In order to use SSO in Shotgun, you need to meet the following criteria:

  1. Be on Super Awesome support.
  2. Use an IdP that supports SAML 2.0. Currently, the following IdPs support SAML 2.0:
  • Active Directory Federated Services (AD FS)
  • Azure Active Directory Federated Services (Azure AD FS)
  • Ping Identity
  • Okta
  • OneLogin
  • G Suite's SAML applications
  1. Test your tools and workflow on a Staging site before we can enable SSO on your production site. If you do not have a Staging site, we can discuss how one can be set up for you.
  2. Attend a 60 minute online onboarding meeting with a representative of our Street team. At this meeting, both Shotgun and SSO Administrators need to be present. This meeting will go over the specifics of the setup and management of SSO in Shotgun. It is also an opportunity to ask questions before we proceed with the setup.


Enabling SSO has a number of side effects. It is important for you to evaluate the impact of SSO on your production pipeline.

  • SSO is an all-or-nothing option: If enabled, everyone will need to use it. If you have vendors or collaborators outside your company, they will also need to use SSO. Your IdP must be accessible by everyone who will need to log on Shotgun. However, playlist sharing will continue to work as it did for the Client Review Site.
  • The iOS Review App supports SSO starting at version 2.0.0. If it is essential to your workflow, you will need to update to the latest version.
  • If you use RV, you will need to update to version 7.3.2 or later.
  • If you use Shotgun Desktop, you will need to reinstall version 1.5.4 or later.
  • If you use Shotgun Toolkit, you need to update to tk-core version 0.18.166 or later.
  • If you use the Shotgun Python API or the Shotgun REST API, it will no longer be possible to connect to Shotgun using only a username and password. Your scripts will need to be modified. Our support team can provide help and advice.
    NOTE: using an API Key and Script Name pair will still function and will not require changes to your scripts or applications.
  • If you depend on internal tools or third party applications, you need to ensure that they support SSO. Your tools will likely need to be modified. Again, we can provide help and advice.

A few notes about user management

While using SSO makes it easier for users to access services without re-entering their credentials, the primary benefit of SSO is increased security. Users and privileges are managed centrally, ensuring that employees who should no longer access Shotgun cannot do so.

By default, Shotgun takes for granted that the IdP is the authoritative reference for information about the users. When a user connects to Shotgun, we will synchronize the information your Shotgun site has about that user with what the IdP provides. While logged on, the user will be automatically re-authenticated against the IdP. Should access to Shotgun be removed for that user, they will be automatically logged out of Shotgun at the time of re-authentication. This process happens roughly every 4.5 minutes.

Even with SSO enabled, the Shotgun Administrators will still need to manage users. It will be necessary to provide users access to projects, and optionally manage their permission group. When transitioning an existing site to SSO, it may be necessary to modify some user information to ensure a seamless transition.

While automatic provisioning is possible in Shotgun, it may not be the ideal option. Users thusly created will likely not have the proper access to their Shotgun projects, resulting in support calls for the Administrators. You may want to create the users in Shotgun, as was done before, in order to ensure that they are assigned to the correct projects and have the proper Permission Group. Access to the Shotgun site itself is still managed at the IdP level.


When using automatic provisioning, user accounts are only created at the moment when the user first connects to the Shotgun site.

Automatic de-provisioning is not supported. When an employee leaves or is assigned to another project, their access to Shotgun should be removed. But the Shotgun user will stay present and active until an Administrator explicitly disables the account.

Note: You will be charged for the user until it is deactivated.

To learn more, please see “Single Sign-On configuration” and “Single Sign-On troubleshooting.”