Why are all users required to use Single Sign-On (SSO) or Multi-Factor Authentication (MFA)?

The security and privacy of your data are our highest priorities at Reltio, and we will continue to uphold the highest standards of data protection and information security to safeguard your tenants and data. SSO is the recommended best practice authentication method for all Reltio customers. Customers choosing not to leverage SSO will have to enable MFA to enhance the security of their Reltio accounts, which can directly access your data. This significantly reduces the risk of unauthorized access, even if a password is compromised. It also helps comply with various regulatory standards and best practices for data protection.

What are the key dates that I need to be aware of for the SSO/MFA rollout?

Key Dates for MFA implementation are as follows:

• SSO is already available for all customers. If you haven’t enabled SSO yet, you can start now.
• September 16, 2024: MFA becomes available for all customers. Customers choosing not to leverage SSO can enable MFA and enroll their users.
• November 4, 2024: MFA requirement for all non-SSO users begins. All users who do not authenticate with a corporate IDP and have not set up MFA will receive Time-Based One-Time Passwords (TOTPs) via email until they complete the enrollment in an authenticator app.

What options do I have for enabling MFA?

There are two options for enabling MFA:

• App-Based MFA (Recommended): Users can generate a Time-Based One-Time Password (TOTP) using an authentication app like Google Authenticator or Microsoft Authenticator. This method is recommended for its higher security.
• Email-Based MFA: Users receive a verification code via email each time they log in. This will be the default MFA method if users do not enroll in an app-based MFA.

How do I enable MFA for my organization?

Administrators will be able to enable MFA by accessing the Reltio Console. We’ll share more details soon.

Will I be able to test MFA in lower environments first?

In Reltio, users can access multiple environments based on permissions rather than being restricted to specific lower or higher environments. However, if you have service accounts designated for different environments, such as a DEV tenant and a PROD tenant, you can effectively apply this concept.

Here’s how you can approach the MFA testing and migration process step-by-step:

1. Enable and test MFA:
   • Starting on September 16, you will be able to enable MFA yourself choosing between email or authenticator as MFA types.
   • You can test MFA with a few selected users initially to ensure it works as expected.
   • Communicate with all your users to manually enroll in MFA through Account Settings.
   • Identify all your service accounts.
2. Service accounts migration for lower environments:
   • Identify the service accounts you use for the DEV/TEST tenant.
   • Migrate these DEV/TEST service accounts to client credentials.
3. Service accounts migration for higher environments:
   • Identify the service accounts you use for the PROD tenant.
   • After successful testing in the DEV/TEST environment, migrate PROD service accounts to client credentials.
4. Final testing:
   • Once the PROD migration is complete, you are done.
5. Full enforcement by November 4:
   • Reltio will enforce MFA for all customers and users not using SSO.
   • If you haven’t enabled MFA, Reltio will enable email-based MFA for you.
   • If users haven't enrolled in MFA yet, they'll be required to enroll in MFA at login.

What's the impact on existing service accounts used for API-only access, and how should we address it?

After SSO/MFA enforcement, legacy service accounts that use only a username and password will face authentication failures. To avoid disruptions, administrators should identify and migrate these service accounts to client credentials before November 4, 2024. This involves creating new client credentials and updating all integration points.

How can we identify and track our service accounts?

Navigate to the Reltio Console, then to User Management. You will see your total list of users and whether they leverage SSO. For the non-SSO users, go individually and determine whether they map to an employee/contractor or are actually service accounts. For additional information, see topic Migrating service accounts from password to client credentials authentication.

What steps should be taken to migrate service accounts to client credentials?

As an administrator:

• Confirm SSO is enabled in their tenants.

• Review the user list by navigating to the Reltio Console, then to User Management.

• Review users with SSO=N and determine whether they map to an employee/contractor or they are actually service accounts.

• For the identified service accounts, create the corresponding client credentials.

  • If you have too many service accounts and want to automate the process, use this script.

• In each source/consumer system leveraging a service account, remove username/password from the authentication request and include client_id and client_secret in the Basic Auth Header.

For more information, see topic Migrating service accounts from password to client credentials authentication

What security measures should be taken when updating our code to use client_credentials?

When updating your code to use client_credentials, ensure that the client ID and secret are not sent via query parameters. These should be included in the Basic Auth header of the POST authentication request to enhance security and prevent the exposure of sensitive information. This is the approved API authentication method:

POST https://auth.reltio.com/oauth/token
Authorization: Basic <BASE64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded
Body:
grant_type=client_credentials

How do we handle exemptions for service accounts?

As an exception, extensions can be requested to migrate specific Service Accounts to client credentials.

To request the extension:

• Identify all Service Accounts (usernames) that need to be exempted. The Reltio team will only grant exemptions on the usernames listed in the email.

• Coordinate with a security stakeholder in your organization on this extension request and your timeline for migration. This should be someone from Security, Risk, or Compliance.

• Send an email to your Customer Success Manager (CSM), either from the security stakeholder or with them copied, with the list of usernames to be exempted and the specific extension date for the associated accounts to be migrated to client credentials

Can I continue using Postman after these changes?

Yes. Postman supports SSO and MFA authentication for API requests, so you can continue using it as usual. Alternatively, a client credential could also be generated for specific use cases.

I have custom-developed code that authenticates to the Reltio API. Should I change it?

Yes, if you still use the username and password in this custom-developed code. Yes, if you are sending credentials via endpoint query parameters. Any custom-developed code, integration, or automated process must use the approved authentication method.

We use ROCS Utilities to authenticate into Reltio APIs. Should I change anything?

ROCS Utilities already supports client credentials, so no change in the code is required. In the parameters file of ROCS Utilities, use the property CLIENT_CREDENTIALS instead of USERNAME/PASSWORD. This property is used to get the access token using the client_credentials grant type. The value for this property can be obtained by encoding the client name and secret separated by a colon in Base64 format: <BASE64(client_id:client_secret)>. Refer to the sample QuickStart file here.