Is new SSO feature optional per-user?

Curious if anyone’s tried the new SSO support yet, and if users can be given a choice of whether to use it or not? Some of our staff will surely want to utilize our existing SAML-based SSO solution to log into their vaults, but those who are more security focused or who have personal info in their vault, will likely want to continue doing pass phrase only.

Right now the SSO function only authenticates a user with an Organization, and the Master Password is still used to encrypt/decrypt user data.

Also, users can still log in with their Master Password (even with SSO enabled0, though we will be bringing an Enterprise Policy to the platform to configure how users are able to access their vault if SSO is enabled.

So the SSO function does not replace/give an alternative to the Master Password to log in? I think I’m confused about what the service actually is, then. I thought it was a way for people to log into their vault and view their passwords without having to use their email address and Master Password to access. Is this not the case? Would they then end up logging in twice (once via SSO, then again with the Master Password) to get to their vault?

1 Like

Scratch this question. Just got a response from Bitwarden on the question I had sent them directly right before I found this post. Turns out it’s an additional layer of security and not an alternative. I thought perhaps it was using SSO instead of the Master Password.

1 Like

It’s a valid question. I’ve updated some of our FAQs to be clearer. It’s really handy to merge into an existing IdP environment for all of the other controls (email/domain control, MFA options, etc) - but of course, we want to maintain the rock-solid security model, and allowing the IdP to control encryption would involve massive changes to our current proven method.

This definitely makes sense, and offers an even tighter level of security. We don’t need that extra level, so my brain went straight to “alternative login” version of the option.

Hi,
Is there anything speaking against a pure SSO-model without master password? It would be nice for enterprise environments, as people either tend to forget their master passwords or just don’t transfer to an organization, which would result in a lost vault if the master pw is forgotten. Also, it is an organization providing the infrastructure, so I’d expect (as an end user), whatever I save in there is property of the company, who’s hosting it (if I have been provided with an organizational access)

1 Like

For clarification then, am I correct that the only thing it’s solving is that an end user could bypass the initial admin invitation to the enterprise org? So now, by way of SSO and auto enroll setting, the invite to the org auto creates to a pending state, and the admin then has to go back in and approve them, just like what is required currently. So we’ve saved the step of the admin inviting them to the org? This doesn’t seem to save much in that regard, and keeps admins as a bottleneck, encouraging an org to have more admins than should really be in there.

Most of our reason for even using organization features is to allow collaboration, but given that requires an admin’s involvement to manage those, and admins retain access to the shared collections, our staff have been reluctant to even request use of the feature as it’s both time consuming and could conflict with regulatory requirements, or customer contractual requirements, where someone shouldn’t have access to the data simply because they happen to be a Bitwarden admin.

I’d see us using the SSO feature if it allowed us to allow it to auto enroll to the org, but our userbase will still likely not be requesting shared collections much because of the other security issue. Self managed collections where the creator controls access is really what we need. If that showed up, and we could SSO enroll people to the org, I’d be all over that upgrade to our plan.