Administrators: Federated Single Sign-On for the Thomson Reuters Account

Federated SSO common questions

If you have any immediate questions, check the following list:
  • Does Thomson Reuters provide staging versions of applications for testing SSO connections?
    • Typically, no, although in some cases this may be possible.  Please discuss with the SSO team if you require this.  Normally you can create a staging and a production connection on your side and both of them will target the same production version of the TR application.  They are treated as two completely independent connections, each with their own user-to-user federation links between your network login and your application logins.  Note when using two connections you must choose separate Issuer URNs since we need to be able to differentiate them.
  • What are the protocol elements to be used for the customer SSO configuration?
    • We will provide an SP metadata XML file that will include all the required information, so normally this XML file can just be imported into your system to set up the connection.  However, for reference, here are two key values you may need:
      • SAML Entity ID: trtasso.thomson.com
      • SAML v2.0 Endpoint: https://trtasso.thomson.com/sp/ACS.saml2
  • My SSO protocol isn't listed, or I want to create a custom protocol.  Can I?
    • No. Thomson Reuters Account supports only the protocols listed in this article.
  • What should I set the NameIdentifier to in the SSO token?
    • Anything you like, subject to the restriction that it be normal text characters no longer than 250 characters in length.  We do not parse or interpret the value in any way. On our side we will store this value in the application’s user profile to create an account link. We recommend a value that does not change for a user over time, such as when an employee marries. Employee IDs, GUIDs or SIDs make good values that meet this recommendation, while email addresses typically do not since they may change over time. 
  • Do I need to change my firewall to support Browser/POST? Does my internal SSO URL need to be publicly visible?
    • No, this profile works by client browser redirects.  Your internal SSO URL need only be visible to your users, not externally by our servers
  • Why am I being asked to provide this information?
    • If as part of a support call we determine that your SSO server appears to be unavailable or is passing us invalid information, we want someone in your organization we can contact to look into and help resolve the problem. We would only do this if we are certain the problem lies on your side of the SSO connection.  We may also contact you if any of your X.509 certificates are expiring soon. If possible, please provide a group distribution list instead of an individual email address so that we won’t lose contact with you if an individual leaves your company.