Requiring SSO for login
Roles and permissions
Only administrators can require SSO for the organization
Overview
If your organization is using SSO via a service platform, you have the option to 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 is 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 checkbox (Settings > Authentication) is selected:
Administrators can log in with SSO, but they can also continue to log in with other methods like Google, Office 365, and email/password. This is to ensure they have a way to fix things if something goes wrong with SSO.
All non-administrators in the organization's internet domain must use SSO.
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 will not be 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.
