Requiring SSO for login
Roles and permissions
Only administrators can require SSO for the organization
Overview
If your organization uses SSO via a service platform, you can make SSO required when users log in to Hyperproof.
Hyperproof supports SSO via Microsoft Entra ID, JumpCloud, Okta, and generic SAML identity provider. Once your administrator has configured the service platform with Hyperproof, and SSO is working properly, it’s highly encouraged that SSO be required to log in to Hyperproof. This ensures that your domain users are going through SSO and not through another method.
Note
Microsoft has renamed Azure AD to Microsoft Entra ID.
How it works
When you configure SSO for a domain, you are "claiming" that domain. All users with an email matching that domain will then be bound to the configured SSO rules, regardless of which organizations those users are actually members of.
In other words, if a user has an email domain associated with a Hyperproof organization that has enforced SSO, regardless of the organization they are associated with, they will be required to log in to Hyperproof via SSO.
Note
A user will not have access to another organization's data unless they are active in that organization.
Example scenario
Luna B. Technologies has configured SSO to be required with the email domain http://lunabtechnologies.com.
Mike Smith is a compliance manager in an organization called WH Technologies, which does not have SSO configured. His email address is mike.smith@lunabtechnologies.com.
Because of his email domain, he will be required to log in to Hyperproof via SSO, but he will not be able to access Luna B. Technologies's Hyperproof instance without being explicitly added to that organization.
Requiring SSO
When the SSO required option (Settings > Authentication) is selected, you have the following options:
Not required - Users log in with other methods, such as Google, Office 365, or email/password.
Required for all users except admins -
Administrators can log in with SSO, but they can also continue to log in with other methods, such as Google, Office 365, or email/password.
This setting allows administrators to address issues with the SSO configuration by logging in to Hyperproof using a separate login mechanism.
All non-administrators in the organization's internet domain must use SSO.
Required for all users -
All users who are part of the organization's internet domain, including administrators, must log in using SSO. No other login methods are permitted.
Selecting this option means that if there is an issue with the SSO configuration, you must contact Hyperproof Customer Support during support hours for help correcting the issue.
For both of the Required options:
Invitations to new users in the organization's internet domain will send them to the SSO login.
You can still invite users from other internet domains, e.g.
jen.cook@abccompany.org. These users aren't bound by SSO. A common use case for this is if you’re working with an external auditor.You can select the Allow IdP-initiated sign-in checkbox to allow users to log in via IdP. For example, on the Okta apps page, users could click the Hyperproof logo to log in.
Note
The Allow IdP-initiated sign-in checkbox isn't displayed in the Hyperproof Gov instance because it is enabled by default in the Hyperproof authentication service provider.