Single sign-on

Single sign-on lets your colleagues reach 3rdRisk from your corporate identity with one click, instead of keeping a separate password for the platform. You configure it yourself under Configuration, test it against your identity provider before it applies to anyone, and switch it on when you are satisfied.

This article covers everything that is the same whichever provider you use. The provider-specific steps — which values to copy out of your identity provider and where to find them — are in a separate article per provider, linked below.

Overview

Single sign-on brings a few things worth having:

• A better sign-in experience, because sign-in prompts largely disappear.

• Wider engagement from occasional users in procurement, finance and the business, because access is one click from the tools they already use.

• Better security, because there is one fewer password to reuse and your own conditional access policies apply.

• Central control, because access follows from group membership and roles in your own directory.

Permissions needed: Configuration settings (read and update). To grant it, navigate to: Left menu: Configuration, then Roles.

To reach the settings, navigate to: Left menu: Configuration, then General, then the SSO tab.

Before you start

• An administrator account with your identity provider, able to register an application.

• A decision on how users are identified, by e-mail address or by User Principal Name. See step 3.

• A decision on what happens to people who do not have an account yet. See step 4. This is the question that most often gets missed, because single sign-on on its own never creates anybody.

Note: nothing changes for your users until you switch Enable SSO on at the end. Saving settings and running a connection test are both safe to do during business hours.

1. Choose your identity provider

Set SSO Provider to the service you use. The list is:

Selecting 3rdRisk at any point returns everyone to e-mail and password, which is also how you switch single sign-on off again.

Note: using another provider that speaks OpenID Connect is often possible. Contact 3rdRiskSupport@diligent.com to discuss it, or use the Need help? action on the SSO tab to open a chat.

2. Enter your provider's details

Choosing a provider reveals a short set of instructions for it on the page itself, along with the fields it needs. Not every provider uses every field:

The Redirect URI is the one value that travels in the other direction: you copy it from this page into your identity provider, which needs to know where to send people back to. It is generated for you, and it has to match in your provider character for character, so paste it rather than retyping it.

Click on Save when the fields are filled in.

3. Decide how users are identified

Username Type decides which value from your provider is matched against the account in 3rdRisk:

• Email address — the default, and correct for most organisations. The address your provider reports must match the address on the 3rdRisk account.

• User Principal Name (UPN) — for directories whose UPNs are not e-mail addresses, or where you want to match on UPN deliberately.

Note: changing this setting later changes which accounts match, so decide it before you go live rather than after.

4. Decide what happens to people without an account

Single sign-on never creates accounts on its own. Someone who authenticates successfully but has no 3rdRisk account is refused, unless you have arranged one of the following.

• Default Roles for New Users, under New users and support on the same tab. Select one or more roles here and an unknown user is created on their first sign-in, holding those roles plus the Login to the platform role that lets them in at all. Leave it empty and no account is ever created automatically.

• Provisioning from your directory, which creates, updates and deactivates accounts ahead of anyone signing in, and drives their roles from group membership. This is the option to choose if you also want off-boarding handled centrally.

Learn more about provisioning: Microsoft Entra ID user provisioning (SCIM)

Note: the roles you pick here apply to everyone created this way, so pick the narrowest role that still lets someone do their job. You can always widen an individual afterwards under Configuration, then Users.

5. Test the connection

Under Validate connection, Click on Test connection. You are sent to your provider to sign in with your own work account and returned to this page with one of three results:

• Succeeded — you authenticated and the account already exists in 3rdRisk. Nothing else to arrange.

• Succeeded, but this user does not exist in the platform — you authenticated, and there is no account for that identity yet. They will be created on first sign-in if you configured Default roles in step 4, and refused if you did not.

• Failed — a detail is wrong, or MFA was required and the sign-in did not satisfy it.

A test stores nothing and leaves single sign-on switched off, so it is safe to run as often as you like.

Note: save your settings before testing. A test never stores the client secret, so testing first and saving afterwards is the usual reason a successful test still leaves the switch locked.

6. Enable single sign-on

Switch Enable SSO on. The switch is deliberately hard to reach by accident, and it stays locked while any of these is true:

• You have unsaved changes on the page.

• No client secret has been saved yet.

• Your provider is Microsoft Entra ID and no connection test has succeeded. Entra ID is the one provider where a passing test is required rather than merely advisable.

Once it is on, everyone on your tenant signs in through your provider. Selecting 3rdRisk as the provider again returns them to e-mail and password.

Multi-factor authentication

There are two separate settings, and they apply to different situations:

• Require two-factor authentication for 3rdRisk sign-in applies only while the provider is 3rdRisk. It makes users set up two-factor authentication in the platform itself. It does nothing once you select an identity provider, because MFA is then your provider's job.

• Require MFA on Microsoft Entra ID sign-in refuses a sign-in when the token from Entra ID does not report that MFA was used. It is a check on your provider's result, not a replacement for your provider's policy — Entra decides whether to challenge, and this decides whether 3rdRisk accepts the outcome.

For Okta, Auth0 and STACKIT, configure the MFA requirement with your provider.

Known limitations

• Single sign-on does not provision accounts. Configure Default roles, or provision from your directory, or every new colleague has to be added in 3rdRisk first.

• A connection test never stores the client secret. Save, then test.

• The redirect URI must match exactly in your provider, including the scheme.

• A passing test is required for Microsoft Entra ID only. For the other providers it is optional, and still the cheapest way to find a mistake before it affects everyone.

• Changing Username Type later changes which accounts match, and can leave people unable to sign in until their account carries the expected value.

Need help?

Use the Need help? action on the SSO tab to open a chat with us, or e-mail 3rdRiskSupport@diligent.com. Please do not send client secrets by e-mail — we never need them, since you enter them yourself and they are stored encrypted.