Single sign-on (SSO)?
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.
True single sign-on allows the user to log in once and access multiple services without re-entering authentication factors.
Types of SSO
Secureframe supports two types:
IdP-initiated SSO
SP-initiated SSO
IdP-initiated SSO
The Identity Provider (IdP) is a trusted, centralized system for managing and storing user credentials and other identifying information. With IdP-initiated SSO, the IdP provides authentication to a variety of dependent applications.
SP-initiated SSO
A Service Provider (SP) is the entity that provides the application or service to the end user. In this case that is Secureframe. With SP-initiated SSO, Secureframe makes the request to an IdP to verify a user that has not already been identified.
Supported IdP vendors
We support all IdPs, including but not limited to what is listed below. You can also create a custom SAML or OIDC connection if your idP and desired protocol are not natively supported.
ADP OpenID Connect
AuthO
Entra ID SAML (For both accessing Secureframe and pulling user and security data)
CAS SAML
ClassLink
Cloudflare
CyberArk SAML
Duo
Google SAML (For both accessing Secureframe and pulling user and security data)
JumpCloud SAML
Keycloak
LastPass
Microsoft AD SF SAML
miniOrange
NetIQ
Okta SAML (For both accessing Secureframe and pulling user and security data)
OneLogin SAML
Oracle SAML
PingFederate SAML
PingOne SAML
Rippling SAML
Salesforce
Shibboleth Generic SAML
Shibboleth Unsolicited SAML
SimpleSAMLphp
VMWare
Configuring SSO
To configure SSO within Secureframe:
In the Secureframe app, navigate to the Company settings page by clicking the profile photo in the top right. Click Company settings.
Click the Authentication Settings tab.
Verify that your desired domain(s) are listed in the row “Step 1 Claim Domain”.
By claiming a domain, you have the ability to restrict access for your personnel. This is a company wide setting found on the Authentication page of Company Settings
To claim a domain, navigate to Settings → Authentication in your Secureframe dashboard. Under Domain Claims, click Claim a Domain, enter your domain (e.g., yoursite.com), and follow the verification instructions. Once verified, you can configure SSO for that domain without contacting support.
For a full walkthrough of domain claiming, see Understanding Domain Claims, SSO, and OAuth.
Once the domain appears, you can toggle login restrictions (see below screenshot) to control how users with claimed domain(s) sign into Secureframe.
Scroll down to the row Configure OIDC or SAML connection. Click Configure. You will be redirected to WorkOS.
If a connection already exists, you may reset it here. At the bottom of the page, click Reset Connection, then type the word “Reset” into the entry field. Then click Reset Connection.
When no connection exists, WorkOS will prompt you to select your IdP. Choose one from the list and WorkOS will provide instructions to complete the configuration.
When configuration steps have been completed you will receive confirmation by email.
Controlling alternate sign-in methods
These switches can be found at the bottom of the Authentication Settings tab to create exceptions and control alternate sign-in methods:
Allow magic link for all domain users:Allows authentication links to be sent to users by email. These magic links allow users to log in directly by clicking on them.
Allow password for all domain users: Allows users with a matching email domain to continue using emails and passwords to log in to Secureframe.
Allow social login for all domain users: Allows users to continue using social logins like Google and Outlook 365 to log in to Secureframe.
Regardless of theses configurations, admins and super admins can always sign in via any methods in case your idP or social login providers have service interruptions.
Restricting SSO and alternate sign-in methods to specific roles
You can control which roles have the ability to set up SSO and control alternate sign-in methods:
In the Secureframe app, navigate to Company Onboarding > Personnel Settings > Roles.
Enable Ability to configure SSO authentication and alternate sign-in methods for roles of your choosing. By default, this setting is only enabled for super admins.
Recommended SSO Solutions
Google Cloud Identity is a great solution for companies already using GSuite. There is a free version that you can deploy to your organization very quickly.
Microsoft Entra ID is a great solution for companies already using Office 365.
Okta has a more robust platform and is a better fit for larger organizations but will often require an annual contract.
Many companies will also charge you additional fees for SSO.
SSO Integration Overview
table below shows which vendor integrations pull single sign-on (SSO) information and shadow IT app information.
Vendor | SSO Information Pulled? | Shadow IT/App Discovery? |
Google Cloud Identity | Yes | Yes |
Google Workspace | Yes | Yes |
Office 365 | Yes | Yes |
Okta | Yes | Yes |
FusionAuth | Yes | Yes |
Duo | No (API Limitation) | No (API Limitation) |
Frequently Asked Questions (FAQ)
Does Secureframe support SCIM?
Yes, we do now support SCIM. Please review this article for full details on how to setup SCIM.
How many connections can I have?
Secureframe supports one connection.
Can we have multiple domains?
Yes, a company can claim multiple domains.
How do I reset a connection?
See step 4 in the procedure Configuring SSO, above.
Does SOC 2 require a formal Single-Sign-On (SSO) solution?
As a good security practice, SSO should be used whenever possible across all organization sizes regardless of your team size.
Why can an Okta integration fail to connect or reconnect, even when the API token is valid?
In some cases, the integration can fail because the user used to authorize the connection is not assigned to the Okta application being connected. When this happens, Okta blocks the authorization request, which prevents the integration from completing—even though the API token itself is still valid
The fix is to ensure that the user performing the connection is explicitly assigned to the relevant Okta application in Okta. Once the assignment is in place, the integration should successfully connect and begin syncing in Secureframe.