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.
• End-August 2024: MFA becomes available for all customers. Customers choosing not to leverage SSO can enable MFA and enroll their users.
• End-October 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.

We will provide more specific dates in future communications.

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 in September, you will be able to enable and enforce MFA yourself.
   • You can test MFA with a few selected users initially to ensure it works as expected.
   • Identify all your service accounts.
   • Create exemptions for all your service accounts.
   • Enforce MFA. This will automatically impact all UI access as service accounts are excluded from MFA already.
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.
   • Remove the exemptions for these DEV/TEST service accounts, ensuring that regular usernames and passwords are blocked for non-production API access.
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, remove the MFA exemptions for these accounts, ensuring that regular usernames and passwords are blocked for production API access.
5. Full enforcement by October-end:
   • By the end of October, Reltio will enforce MFA for all customers.
   • After this enforcement, exemptions will be ignored, and username and password authentication will not be allowed for any environment.

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 the end of October 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.

We are working on a few UI enhancements to show more data and allow additional filtering. In the meantime, you can reach out to Reltio Support to obtain a customer-specific report with potential service accounts that Reltio has identified.

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

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?

Along with MFA, Reltio will also release temporary MFA exclusions. Reltio will create a SERVICE_ACCOUNTS group. This group will be automatically excluded from MFA. This method will allow customers to enable MFA as soon as possible for non-SSO users without disrupting their service accounts. However, all exemptions will be removed after the end of October 2024. We’ll share more details soon.

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.