Skip to main content

Legal

Featured

Questions? We are here to help
Contact us

Tax & Accounting

Featured

Questions? We are here to help
Contact us

Trade & Supply

Featured

Questions? We are here to help
Contact us

Risk & Fraud

News & Media

Books

Developers

Single sign on

Single sign-on authentication

Thomson Reuters uses the PingFederate solution from Ping Identity for our Federated single sign-on (SSO), including ONESOURCE. This capability enables you to authenticate on your corporate network first and then automatically authenticate to Thomson Reuters applications with single sign-on (SSO) technology.
Thomson Reuters supports the SAML 2.0 protocol. This is by far the most common SSO protocol in use today. We support both SP and IdP-initiated SSO using the Browser/POST profile.
Thomson Reuters doesn't support any other SSO protocols, including non-standard, customer-specific custom protocols.

Authenticate using SSO

After logging in to your corporate network, you'll have direct access to your application. If you don't have an SSO, you'll authenticate twice. You'll sign in to your corporate network and then sign in to a Thomson Reuters application such as ONESOURCE Platform.
note
ONESOURCE Platform doesn't support single logout (SLO), and we haven't added this capability in PingFederate. For control over the customer authentication session, you can manage that on the customer side. If you need to reauthentication if a user tries to use the customer IDP to get back to ONESOURCE, you can enforce that with a policy on your side. In practice, the industry doesn’t support SLO.

Single sign-on for specific ONESOURCE applications

For ONESOURCE applications, users can only directly single sign-on into the ONESOURCE Platform web portal as the target application. ONESOURCE applications use the normal launching mechanisms for access, like ONESOURCE Income Tax or ONESOURCE Tax Provision. The ONESOURCE Platform supports immediately launching a specific ONESOURCE application during the single sign-on sign in for customers that always use a specific application through an additional parameter on the target application URL (like "?OSTARGET=https://www.application.com".
note
The ONESOURCE Platform window displays along with the launched target application.

SSO versus user provisioning in ONESOURCE

ONESOURCE supports SSO for authentication. It doesn’t support SCIM, JIT, or Okta-based user provisioning. You'll need to create users manually in ONESOURCE by import or via the User/Access Control APIs. Then you'll link them to the SSO.
What's supported
Customers can integrate their IdP (for example, Okta, AuthBlue) with ONESOURCE for authentication (AuthN).
What isn't supported
SCIM, JIT role or user provisioning, or any direct Okta or SailPoint connector to create or update users in ONESOURCE isn't supported.
How to provision users
  • Create users manually in Administration.
  • Import users in bulk using the CSV template.
  • Use APIs to create or update users and assign roles or groups. The customer (or TR services) will need to build and host the integration that calls ONESOURCE APIs.

This article applies to:

  • PRODUCT: ONESOURCE Platform
  • Sub-Product: ONESOURCE Administration