Configuring Single Sign-On (SSO)
SSO is an authentication process that allows users to access multiple applications after only signing in once. Diligent One supports SSO integration for any identity provider that adheres to the OASIS SAML 2.0 protocol.
Diligent One provides limited support for SSO as other authentication scenarios present a potential security risk to companies.
Permissions
Only System Admins can configure SSO settings for their company.
Requirements
- Your identity provider must adhere to the OASIS SAML 2.0 protocol.
- All users of an SSO-enabled instance of Diligent One must authenticate through an identity provider.
If your users access multiple instances
Users who authenticate through an identity provider can do so for multiple Diligent One instances if all of these instances belong to the same company.
To check this, look at "Customer name" in the organization settings for each instance. It must be the same in all instances that SSO users need to access. For more information, see Updating organization settings. Alternatively, you can use the instance switcher to verify that the instances in question are indented below the same company name. For more information, see Switching between Diligent One instances.
If you need to change which company your instance belongs to, contact Support.
Authentication is not region-specific. Users can access Diligent One instances in multiple regions.
If your users access training instances
Users who authenticate through an identity provider can create training instances, which are automatically linked to the same company.
Additional users can be added to this training instance as long as those users do not already belong to a different training instance with the same email.
If your users work for multiple companies
Users who work for multiple companies (for example, consultants) cannot use SSO.
If a Diligent One user at your company already uses an SSO-enabled instance that belongs to another company, you cannot enable SSO. To enable SSO, you must either remove that user from Diligent One at your company, or ask them to have themselves removed from the other company's Diligent One.
You cannot use SSO and 2FA together
You cannot use two-factor authentication with single sign on. If you need to use both SSO and 2FA, you should use your SSO identify provider's own 2FA ability. If SSO is enabled, Diligent One does not permit you to turn on 2FA. Likewise, if any member of your instance uses 2FA, Diligent One does not permit you to turn on SSO.
How to enable SSO
To enable SSO for Diligent One you need to perform a few tasks:
- Configure SSO settings in your identity provider.
- Enable SSO in Launchpad.
- Open Launchpad.
- Click Platform Settings > Organization.
- Click Manage SSO settings.
- Fill out the SSO fields, which are detailed below, and check Enable Single Sign On (SSO).
- Click Save Changes.
- Add users to an SSO enabled instance.
To link Diligent One with your identity provider, you must specify the first name, last name, and email address for all users. For more information, see Methods for adding users.
For detailed configuration information, search for SSO articles in Support.
SSO fields
| Field | Definition |
|---|---|
| Custom Domain |
The unique name that identifies your instance, and enables users in your company to sign in to Diligent One. The custom domain is your instance's subdomain appended with a region code. Note
You can change your instance's subdomain on the Update Organization page. For more information, see Updating organization settings. |
| Entity ID | The URL that identifies the identity provider issuing a SAML request. This is a URL specific to your identity provider. |
| Metadata URL | The URL that Launchpad can access to obtain SSO configuration data from your identity provider. This is a URL specific to your identity provider. |
| Redirect Login URL |
The URL of your identity provider for users in the company to sign in to Diligent One. |
| Logout URL | The URL to which Diligent One will redirect the users in the company after they sign out of Diligent One. |
| Security Certificate Fingerprint |
The SHA-1 or SHA-256 fingerprint of the SAML certificate that can be obtained from your identity provider. Note When Diligent One is the service provider, the identity provider must encrypt the SAML response and you must configure the Security Certificate Fingerprint in Launchpad. |
| Enable Single Sign On (SSO) | Enables SSO for this instance. |
Launchpad service provider URLs
When configuring your SSO identity provider, you may require the following service provider URLs for Launchpad:
- Service provider entity ID https://accounts.highbond.com/saml/metadata/your_custom_domain
- Service provider assertion consumer URL https://accounts.highbond.com/saml/sso/consume/your_custom_domain
How to log in when SSO is enabled
There are two ways users can log in when SSO is enabled.
What happens when SSO is enabled?
When SSO is enabled, you can sign in by going to www.highbond.com, clicking Sign in to a custom domain, and providing your custom domain.
Alternatively, you can access Diligent One using the Diligent One app link from your identity provider landing page.
You are redirected to Diligent One via your identity provider when you access any Diligent One apps (including clicking on a link in an email sent from Diligent One).
Once SSO is enabled, you cannot sign in with your email and password or change your password.
Email addresses cannot be changed when SSO is enabled. However, if email addresses require changes, the System Admin needs to disable SSO in Diligent One, make the required changes to the email addresses, and re-enable SSO. Otherwise, changed emails are identified as new accounts, and users will not be able to access information from their previous credential.
Do I need to enter my custom domain each time I sign in?
- If you sign in through your identity provider, you do not have to provide a custom domain each time.
- If you sign in through Diligent One, you can access the following URL to avoid entering a custom domain each time: https://accounts.highbond.com/saml/sso?custom_domain=your-custom-domain
Signing into multiple instances of Diligent One
If you have access to multiple instances of Diligent One, you are brought to the instance you used most recently. You can switch instances normally. For more information, see Switching between Diligent One instances.
How to log out when SSO is enabled
Diligent One supports SLO (Single Log-Out) using the identity provider initiated workflow. The SLO URL is:
https://accounts.highbond.com/saml/slo/your-custom-domain
How session expiry works
When a Diligent One session expires, or when you attempt to log out of Diligent One, you must first log out of your identity provider. Otherwise, you are automatically signed back in to Diligent One.
For example, if your instance's session expiry is three hours and your identity provider's session expiry is three days, you will be automatically signed in to Diligent One for three days.
For security purposes, your company should ensure that your identity provider's expiry is less than your instance's session expiry.
You can change your instance's session expiry on the Update Organization page. For more information, see Updating organization settings.
What happens when you add someone to an SSO instance of Diligent One
Diligent One supports JIT (Just-in-Time) provisioning for SAML. When a user logs in for the first time, a corresponding user account with the same email is created in Diligent One.
Matching email addresses and domain accounts
Diligent determines the user's preferred identity provider and user name. The email address and domain account of each user must match. If the user's email address and domain account do not match, you must set up an alias for the user in your directory access service.
Subscriptions and access to Diligent One apps
The user will have no subscriptions assigned, nor access to any Diligent One apps. System Admins must assign users a role and subscription in Launchpad to ensure users have appropriate access in the instance.
Disabling SSO
If your company enables SSO, and later decides to disable it:
- Users who did not set up a password before SSO was enabled must click Reset password on the login page to obtain a password.
- Users who set up a password before SSO was enabled can login with their user name and password.
SSO and SAML
Diligent One supports SSO integration for any identity provider that adheres to the OASIS SAML 2.0 protocol.
What is OASIS SAML 2.0?
SSO enables users to sign in using OASIS Security Assertion Markup Language 2.0 (SAML 2.0), a format for communicating and authenticating identities between two web applications.
OASIS SAML 2.0 involves:
- a user requesting service
- a service provider or application providing service (Diligent One)
- an identity provider or repository that manages user information
For instances with SSO enabled, users are authenticated when they sign in to Diligent One using a supported SAML identity provider. If the user is not enabled in their company's SAML identity provider, the user is denied access.
Supported workflows
Once SSO settings have been configured, the following workflows are supported:
- Identity provider initiated - accessing Diligent One from the identity provider landing page.
- Service provider initiated - accessing Diligent One from the Diligent One home page.
Identity provider initiated authentication process
Service provider initiated authentication process
Offboarding users who leave
If a user leaves your company, your offboarding process will likely remove them from your identity provider. How exactly this affects users depends on which instances they had access to and how those instances were configured.
- If the user was only part of your SSO-enabled instance(s), they can no longer access those instances on Diligent One.
- If the user was part of your SSO-enabled instance(s), plus other non-SSO instances:
- If you remove the user from your identity provider, they will not be able to access any instances of Diligent One. If they try to access a non-SSO instance, they will see the error message, “Your organization has enabled Single Sign-on, please sign in to your organization’s custom domain.”
- If you manually remove the user from the SSO-enabled instance(s), they can still access non-SSO instances once they reset their password.
