Act as a SAML service provider for onboarding

It should be possible to make Bitwarden behave as an SAML service provider, though a user would still need to input their master password for Bitwarden each time. This would mostly be beneficial for companies to aid in on-boarding of users and control things like 2FA on their side. A true SSO implementation is not really possible due to the master password (encryption key) requirements of Bitwarden.

GitHub issue:

We also need this feature as currently, we are moving all our services under Okta SSO and where it is possible adding provisioning for users, so in general, Okta acts now as our users’ management system.
Bitwarden is one of the most critical components in our security system, so it will be great to have the ability to integrate it into the whole system fully.
So, it will be great to have both features - SAML SP and users provisioning, to avoid adding them manually and especially - to avoid letting them set a password via invite emails, as also we are trying to implement passwordless authentification - users will have access only via Okta’s application.

It’s unfortunately not clear to me how lastpass achieve this, but they do.
Having the ability to use the Active Directory credentials to access the bitwarden account would be, i think, the only remaining reason we’re still considering lastpass.
(on the basis bitwarden already has the groups and user provisioning functionality in the bitwarden directory connector)

Yes, we need this as well. We are using Azure AD Premium with MFA, and we don’t want to setup another system for MFA.

We will postpone our migration to Bitwarden until this feature is available.

We are in the same position, using Azure AD Premium for our SSO and MFA needs.
The current system isn’t really build for business but Keeper seems to have a good implementation.

We will eventually start an eval if we can get the resources for it.

This would be really interesting - I dont think its a major issue having the user type a bitwarden password, as the main advatange would be user provisioning, 2fa, handled by the IdP.

But, maybe there are some fields that are part of the users SAML identity that could be used to derive the encryption key? Or could be used as part of the input to the key generation - would that improve the security in some way?

LastPass’ SSO implementation (including the generation of a hidden master password) is described here under the section “LastPass Federated Login Services” on page 12. This is how they are able to support SSO without having the user enter a second password and still meet their “zero-knowledge” policy.

The strategy varies slightly by identity provider but ultimately the user’s master password is derived from multiple key parts, one part typically stored at the identity provider (IdP) as a “user account attribute” (e.g. ADFS/AD) and one or more at the password store service provider (e.g. LastPass). A secondary mechanism is used for synchronization of user status (e.g. LastPass Active Directory Connector).

My Thoughts
I believe this strategy permits the IdP to decrypt the user’s vault if they desire (whether by impersonation or simply having access to both the IdP and SP key parts). This might be a negative for the user but might be a positive for the entity (e.g. an enterprise needing to access a deceased/terminated employee’s credentials). Assuming Bitwarden went with this strategy, I’d think it would make sense to have an admin-level setting such as, “Allow users to override hidden master password”. If turned on, the user could be prompted at provisioning to provide an optional master password and the pros and cons of doing so; a “pro” being that the IdP could not decrypt their data and “con” being they’d have to provide the password every time.

Is this what’s being implemented here?

If so, to what degree? Are you using a similar strategy as LastPass as I referenced above?

Hi @gtbuchanan - it’s authentication via SAML/OpenID, the decryption is still performed by your master password.