Teamgage

Using SAML authentication to provide a single sign-on experience for your organisation’s users can enhance your users’ experience in using Teamgage.

Note that for users who only use Teamgage to submit their results and comments, we do not require authentication and so nothing will change.  The users who will benefit from a SSO experience are the managers, report viewers and administrators.

Once configuration is complete, when your organisation’s managers log in to Teamgage they will be asked to enter their email address, but will then be redirected to your SAML provider for authentication. If they are already authenticated with SAML, they should automatically be redirected back to Teamgage with their expected access.

Not using SAML? Teamgage also supports Single Sign-On with Azure AD.

Setup Process

Configuring your Teamgage account for SSO proceeds in two phases:

• User Acceptance Test: connect your SAML identity provider to the Teamgage UAT environment.
  https://uat.teamgage.com/
• Production launch: connect to Teamgage production and scheduled cut-over for existing users.
  https://www.teamgage.com/

Each phase consists of the following steps:

1. IdP configuration: Your IT staff configure your Identity Provider with the Teamgage settings.
2. SSO setup request: You provide Teamgage with the required information:
   • email domains used within your organisation (through this identity provider)
   • your SAML IdP metadata URL
3. SP configuration: Teamgage configures your organisation for SSO and performs cut-over.
4. Validation: You and Teamgage test for successful login using SSO.
   
   

Configuration Guides

Step-by-step configuration guides are available for the following platforms:

• Okta (with App Integration) - type Teamgage into the search box
• Active Directory Federation Services (ADFS) 

Other SAML 2.0 Identity Providers can be set up using the configuration details below.

Configuration Details

To connect to Teamgage, configure a new SAML 2.0 Application (or SP/Relying Party) in your Identity Provider as follows:

Metadata URL

• UAT:
  https://uat.teamgage.com/Saml2
• Production:
  https://www.teamgage.com/Saml2
  Recommended: Enable "Automatic update"/polling.

Attributes

• NameID (some providers require this to be added explicitly)
• Email:
  • Attribute Name:
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailidentifier
  • Attribute Name Format:
    URI Format
  • Value:
    user email address

Manual Configuration

If you need to provide manual SAML SP configuration, the following additional details may be useful. This is also encoded in the metadata file (URL linked above).

Important: Manual configurations will require you to manually reconfigure the signing certificate from time to time. Please contact support to ensure that you are notified when we rotate to a new certificate.

Additional Information

• Which SAML Profile and methods are supported?
  Teamgage currently supports the Web Browser SSO Profile with SP Redirect Request and IdP POST Response.
• Which sign-in flows are supported?
  Teamgage supports SP-initiated SSO. We do not currently support IdP-initiated SSO, so all sign-in requests must initiate from the Teamgage login page to generate a valid nonce.
• What is the NameID format, behaviour and restrictions?
  The NameID value must be sufficiently unique to the user and no longer than 128 characters.
  We recommend using the user's object GUID; if this is not possible then the username or email could be used.
  The NameID format is unspecified, and will behave correctly with both persistent and transient semantics. Each new NameID received is associated to a user account using the email attribute, and will be reused for subsequent requests.
• How are signing certificates rotated?
  • SP (Teamgage) certificate
    When our existing signing certificate is approaching expiry, a new certificate will be generated and published in our metadata (alongside the existing certificate).
    We will switch to signing with this certificate no earlier than 1 month after it is published to our metadata.
    If you have configured your IdP using the metadata URL with polling (at least once a month) then this rotation will occur automatically.
    If you have performed manual configuration, please contact support to ensure that you are notified when we rotate to a new certificate.
  • IdP (customer) certificate
    We will periodically poll your application's metadata URL, and will trust authorisation responses signed by any signing certificate listed in this metadata.
    Please ensure new certificates are included in your metadata at least 1 week before it is used for signing, and that the old certificate is also included until it is no longer being used for signing.
    If you are not able to publish the new certificate in advance, please contact support to schedule a manual certificate update.