Single sign-on (SSO)

Note: SSO is only available to clients on Super Awesome Support.

Important note

Using SSO on your side will have the following effects:

  • If you use RV in your studio, you will need an updated version of RV (7.2.0 and later)
  • If you use the Shotgun Desktop or the Toolkit, you will also need to update to a version that supports SSO (exact version TBD)
  • If you use the shotgun_api3 python module, you will no longer be able to use the user_login/user_password pair method to create a new sessions.

As an Admin, you can access the single sign-on (SSO) configuration under Site Preferences > Authentication.

The first time you log in after enabling SSO, you will be prompted to use your organization’s username and password.

SSO

SSO works with both Shotgun and RV.

SSO in RV

If SSO is enabled, RV users will see an error message if they try to sign in without SSO.

RV error message

Using SSO

As a user, once you log in via SSO, your Shotgun site should look the same. However, your username may be different, depending on your organization’s login.

As an Admin, you will notice the following changes:

  • You will no longer be able to reset user passwords. This will be controlled by your studio’s IT department.
  • You will no longer be able to test Shotgun under different users, only under your own account, unless your organization issues you additional user names.
  • Users are created when logging in. If Shotgun doesn’t have an existing user with that login ID, it will be created. Note that renaming an existing user may result in creating duplicate users.
  • If you change a user’s first name, last name, full name, or email, those fields will be reset to the original when the user logs in. This is because that information comes from your organization’s IT department.
  • Your organization’s IT department must grant both new and existing users access to your site.
  • You can invite new users and create new users for your site. Shotgun will send them a welcome email and they can use their SSO account to sign in.
    • Invite user to Shotgun
    • Create person in Shotgun

SSO provides the following abilities to your Shotgun site:

  • Centralize permission management,
  • Grant and revoke Shotgun access from the SSO system, and
  • Synchronize user information, such as name and email, between the SSO system and Shotgun.

Configuration

Enabling SSO requires minimal configuration.

Note: SSO uses the Security Assertion Markup Language (SAML) authentication. Do not activate SAML before completely configuring and testing it.
    1. Set your basic parameters under SAML authentication. (See chapter 8.3.6 in http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf for more information.):
      1. Public certificate: The certificate will be used to encrypt and decrypt your requests.
      2. SAML 2.0 endpoint (HTTPS): The endpoint which will be contacted to validate your credentials. For example, "https://single.login.url".
      3. Identity provider issuer: The ID your service will use.
    2. Test the SAML authentication by clicking on the test button.
      Test SAML
      Accept new tabs to verify if you can log in.
    3. If the test succeeds, set "SAML Authentication" as your authentication method.
      Set SAML Authentication

Other options

The YAML configuration will be covered at the end of this article.

Enabling and disabling SSO

Admins can enable and disable SSO. You will receive an email each time you enable or disable SSO.

Enable SSO

If you disable SSO, you can use your old Shotgun username and password to log in.

Disable SSO

If you did not have a Shotgun account before SSO was enabled, you will receive an email that allows you to reset your password.

Reset password

SAML2 Configuration

Contract

The Active Directory SAML2 response must provide five attributes:

Name Type Presence Details
login_id string Mandatory The ID the user will have in Shotgun. This must be unique within Shotgun.
firstname string Mandatory The user's first name.
lastname string Mandatory The user's last name.
email string Mandatory The user's email address.
access string: true/false Mandatory If 'true', the user will have access to Shotgun.
groups string Optional 

If it is not present, or empty, the user's permission group will not be modified from its current value. For a new user, the default user permission group will be used, as defined in the Site Preferences.

If it is present, it should correspond to the name of one of the permission groups defined in Shotgun. If the name does not match, the user will be granted the default user permission group.

ex: "Admin"

Session duration is based on the SAML response:

  • If saml:AuthnStatement contains a field SessionNotOnOrAfter, that field will indicate a session's duration.
  • Otherwise the saml:Conditions field NotOnOrAfter indicates a session duration.

At the end of the session, renewal may require users to enter their credentials.

Example

Below is an example of a valid SAML answer for Shotgun. (Note that relevant fields have been removed.)

SAML2 response:

[...]
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                         NameQualifier="https://your.sso-service.com/saml2"
                         SPNameQualifier="https://your.site.com/saml/metadata"
                         >ziP0wDQy0yS1kFg8DmyzqQpaD0a</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData Recipient="https://your.site.com/saml/saml_login_response"
                                              NotOnOrAfter="2017-01-23T16:53:01.292Z"
                                              InResponseTo="_8fde3e06-9c0b-4c55-bf14-85e82aef9e4b"
                                              />
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2017-01-23T16:48:01.292Z"
                         NotOnOrAfter="2017-01-23T16:53:01.292Z"
                         >
        </saml:Conditions>
[...]
        <saml:AttributeStatement>
            <saml:Attribute Name="login_id"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >a_username</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="firstname"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >a_firstame</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="access"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >true</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="groups"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >Admin</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="email"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >a_user@your.site.com</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="lastname"
                            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                            >
                <saml:AttributeValue xsi:type="xs:string"
                                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     >a_lastname</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

Encryption and other options

Encryption

Every call from the Identity Provider (IdP) is encrypted with the certificate. By default every call to the IdP isn't encrypted. It's possible to force the encryption by providing the right options in the YAML.

YAML extra configuration

To enter supplementary configuration, use the SSO Configuration (YAML format) edit box.

As is implied by its name, you must use the YAML format, with proper section headings.

Here are examples for additional encryption and Single log-out (SLO) settings:

Encryption:

service_provider:
  private_key: "KEY" #the key used for encryption
security:
  authn_requests_signed: false # authorisation requests are encrypted
  logout_requests_signed: false # logout requests are encrypted
  logout_responses_signed: false # logout responses are encrypted

Single Log Out:

identity_provider:
  slo_target_url: "https://single.logout.url"
Follow

2 Comments

  • 0
    Avatar
    Sachin Shrestha

    Does the new SSO option change anything for accessing the hosted shotgun site from outside a studio environment or do the IP filtering rules still apply?

  • 0
    Avatar
    Patrick Hubert

    Hi Sachin,

    The Identity Provider (IdP) site must also be accessible from outside the studio environment for SSO to work.

    The Shogun Server never directly connects to the IdP Server (or vice-versa). All the interactions are done via the user's browser. As long as they can connect to both, all should be good.

Please sign in to leave a comment.