IT administrators must constantly balance convenience and security. With Login with SSO, you can maximize flexibility while maintaining the utmost security for your Organization. In this blog post, we offer Organizational best practices to configuring Login with SSO.

Flexibility with Single Sign-on

Choices abound to manage enterprise users and their identities, including dozens of ways to add extra security and authentication layers, and even more ways to deploy them. That’s a lot to keep up with! Bitwarden gives you the flexibility to integrate the same tools you use at work every day.

This is why Login with SSO for Bitwarden is a 100% direct integration with your existing Identity Provider. As long as your Bitwarden server or our cloud-hosted server can access and pass data to and from your SAML 2.0 or OpenId Connect Identify Provider, you can leverage this solution - no third party or middle layers needed.

Login with SSO is available on all current Enterprise plans. For more information on those plans please visit our the article here.

Connect Your Existing Identity Provider

Login with SSO allows your existing Identity Provider or directory service to provide authentication into your Bitwarden account. This makes logging in easier and more secure than using just your Bitwarden email and password, giving an additional convenience of being able to use any existing extra authentication mechanisms that you may currently use in your enterprise.

For more information on configuring Login with SSO and supported protocols, check out our documentation here.

Set User Authentication Rules

By default, when a Bitwarden user account is created, users log into their Bitwarden Vault by using their email address and Master Password. This option allows users who may not be enrolled in an organization directory to access their Vault.

If your Identity Provider’s directory includes all of your users, and you want to require them to authenticate via SSO, you can enable this in the Business Portal via an Enterprise Policy.

There are two parts to this configuration:

Restricting a user to a single organization ensures that there are no overlapping or conflicting policies, allowing Administrators to rest easy knowing that this set security policy will be maintained for all users.

Once users are restricted to a single organization, that user can be configured to authentication only via Login with SSO, and will no longer be able to log in using their email and Master Password.

Note A user will still be required to enter their Master Password for encryption/decryption purposes.

For more details on configuring these Enterprise Policies, check out the article here.

Alternate Authentication Methods

Administrators will still have the ability to log in using just their email and Master Password, in the event that you need to change Identity Provider configuration settings or even if your Identity Provider is having issues.

Additionally, the CLI application can leverage an API key now, so you don’t have to worry about authentication via SSO on headless/browserless automation systems where this may not be possible.