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.

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)
  • Ping Identity
  • Okta
  • OneLogin
  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.

Constraints

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 does not yet support SSO. If it is essential to your workflow, you will no longer be able to use it.
  • If you use RV, you will need to update to version 7.2.5 or later. RV on Mac OSX doesn’t support TLS v1.2 yet.
  • If you use Shotgun Desktop, you will need to reinstall version 1.5.3 or later.
  • If you use Shotgun Toolkit, you need to update to tk-core version 0.18.151 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.

Provisioning

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

Follow

2 Comments

  • 0
    Avatar
    Michael Oliver

    Can you please clarify the line "But the Shotgun user will stay present and active until an Administrator explicitly disables the account".  Does this mean that

    • the user will be denied access (because the SSO authority will deny) but the user will remain active in Shotgun for billing purposes as well as show as active for things like task assignment and notes? 
    • or will the user will continue to be able to sign in to Shotgun even though their account in the SSO authority will be disabled?

     

  • 0
    Avatar
    Patrick Hubert

    When an employee leaves the company, or no longer require access to Shotgun, the SSO authority will remove the user from the list of those who have access.

    So that user is no longer able to access Shotgun, even if their user is still active.

    The issue here is that you will still be billed for that active user which no one can actually use. We unfortunately do not presently offer de-provisioning functionalities.

    When there are removal of user at the SSO level, the Shotgun Administrator should also be notified (via email, phone call, sms, etc.) that they should disable the corresponding user in Shotgun. This purely to avoid being billed unduly for that user.

Please sign in to leave a comment.