SAML 2.0 Configuration
Users who authenticate their identity using SSO will be required to enter an SSO identifier that indicates the organization (and therefore, the SSO integration) to authenticate against. To set a unique SSO Identifier:
Log in to your web vault and open your organization.
Open the Settings tab, select Single sign-on, and enter a unique SSO Identifier for your organization:
Save your changes before exiting this page.
You will need to share this value with users once the configuration is ready to be used.
Once you have your SSO identifier, you can proceed to enabling and configuring your integration. To enable login with SSO:
From the organization vault, navigate to the Settings tab and select Single sign-on from the left-hand menu:
On the Single sign-on screen, check the Allow SSO authentication checkbox.
From the Type dropdown menu, select the SAML 2.0 option. If you intend to use OIDC instead, switch over to the OIDC Configuration Guide.
You can turn off the Set a unique SP entity ID option at this stage if you wish. Doing so will remove your organization ID from your SP entity ID value, however in almost all cases it is recommended to leave this option on.
From this point on, implementation will vary provider-to-provider. Jump to one of our specific implementation guides for help completing the configuration process:
The following sections will define fields available during single sign-on configuration, agnostic of which IdP you are integration with. Fields that must be configured will be marked (required).
Unless you are comfortable with SAML 2.0, we recommend using one of the above implementation guides instead of the following generic material.
The single sign-on screen separates configuration into two sections:
SAML Service Provider Configuration will determine the format of SAML requests.
SAML Identity Provider Configuration will determine the format to expect for SAML responses.
Service Provider Configuration
Identity Provider Configuration
When completing the X509 certificate, take note of the expiration date. Certificates will have to be renewed in order to prevent any disruptions in service to SSO end users. If a certificate has expired, Admin and Owner accounts will always be able to log in with email address and master password.
SAML attributes & claims
An email address is required for account provisioning, which can be passed as any of the attributes or claims in the following table.
A unique user identifier is also highly recommended. If absent, email will be used in its place to link the user.
Attributes/claims are listed in order of preference for matching, including fallbacks where applicable: