I’ve been getting the run-around from support via email who seem unable to answer this question (is Bitwarden support a bot?). When I’m at the sign in page on the website or any app, there’s an option to sign in with SSO or Master Password. When I select SSO it jumps me over to my Microsoft sign in dialog where I can sign in if I’m not already. Then it asks me to enter my Master Password. Or, I can ignore the SSO and just sign in with my Master Password. Every other service we use SSO for just utilizes our Microsoft Azure connection and passes the authentication over to access the service without the need for a secondary password.
Why does SSO exist as a sign in option at all if it serves no purpose?
Keep in mind that if you are an owner or admin you may not be subject to the same enterprise policies in place for your organization such as require SSO login.
Hence you can still sign in with just the master password bypassing the SSO login requirement. This can help in the case that you may be locked out of the SSO provider, or there is some service connection issue with the IDP. If you are self-hosting your Bitwarden server you can disable this and require SSO login for all users, Owners and admins alike if you wish.
Remember that Bitwarden’s zero-knowledge encryption architecture means only you ever hold your keys to decrypt your data and Bitwarden never receives your master password. This is needed for both authentication to prove you own your encrypted vault, which is then sent to your machine where that same master password can decrypt the blob locally.
Login with SSO decouples the authentication and decryption process, and allows for authentication against a supported IDP of your choice. This can help enforce things such as master password requirements, and rotation frequency, as well as enforcing 2FA methods and conditional access policies in your environment as needed.
For more info you may also find the following article helpful.
Though if you are self-hosting, there is also the optional Key connector in which you can manage your Users’ vault encryption key, getting rid of the need for the master password to still encrypt/decrypt the vault contents.
Though I do believe the Bitwarden team is actively looking into ways to allow for this same type of self managed key connector for the Saas cloud offering, but nothing further past initial research at this time.
Ok, I think I understand now. I had to create a test-user account to understand what no one has been able to clearly explain.
Signing in with SSO for Owners/Admins does not exist.
Users must sign in with both SSO and Master Password.
We’re not self-hosting. Require SSO policy is enabled.
And the only way to allow users to sign in with only SSO, like they do with the dozen other services we employ, is to self-host and use the Key Connector.
Do I have that correct?
I have to note, for our team and the type of users we employ, adding additional steps is going to dissuade them from using something. The entire point of SSO, from our perspective, is to eliminate friction and encourage people to use the services we adopt to make their jobs easier. If what I’m understanding about the Bitwarden authentication process is accurate, it would make more sense for us to disable SSO. Or, more likely, use a different password service.
Hi @anthony_S123, Many Bitwarden customers make use of the SSO integration to easily add and de-provision accounts that have access to the Organization, particularly larger companies managing hundreds to thousands of users. The use of Login with SSO and decryption with the master password ensures that only the individual users have their decryption key, not anyone else and not the Identity Provider.
For customers self-hosting there are options to host decryption keys locally.
Benefits of the existing solution are outlined in this post Integrated Password Security with Identity-based SSO | Bitwarden Blog and there are more integration options planned that will offer additional choices.
Can anyone in this company or someone with a normal brain around here answer my question?
Signing in with SSO for Owners/Admins does not exist.
Users must sign in with both SSO and Master Password.
We’re not self-hosting. Require SSO policy is enabled.
And the only way to allow users to sign in with only SSO, like they do with the dozen other services we employ, is to self-host and use the Key Connector.
Do I have that correct?
Why is it that everyone in this company is incapable of answer a simple question and only capable of regurgitating marketing? This is at least the sixth time I have asked the same question and I have still yet to get a simple answer. Is this company just operated by AI? I really don’t get it. If this is the type of “support” I can expect, I think this is the last nail in the coffin and we’ll need to look elsewhere.
I’m just an end-user like yourself, but in my own deployment/configuration, I found this statement to be true. For my use case, we don’t want to escrow our end-user’s encryption keys, so self-hosting was taken off the table.
My largest frustration is the ‘workflow’ of Bitwarden’s SSO – in most places, if ‘require SSO’ is enabled, as soon as you put your email address in, it takes you to your IdP for authorization. This implementation doesn’t “require” the user to click on ‘log in with single-sign on’ until after they’ve gone through the user>pass>2fa process before throwing an error about ‘requiring sso.’ To me, that is a very anti-user approach.
The ‘user vault’ encryption password you mentioned could be explained to end-users as ‘enhanced security’ on their account.
Hi @anthony_S123 ,
Sign in with SSO for Owners/Admins does exist, but it is not required. That way if the IdP is unavailable, Bitwarden remains available to owners/admins. There is an option to require it within the self-hosting configuration.
Users log in with SSO and decrypt with their master password today. Or they can use the key connector. More options are coming here too.
As an end-to-end encrypted application, Bitwarden is a bit different than your typical SaaS application when it comes to SSO in order to protect the zero knowledge encryption approach.
Thanks Gary. As of now, as I’ve outlined, Owner/Admins can access their account by only using the Master Password and not authenticating using SSO. And by choosing sign in with SSO it still requires the Master Password. So it seems, in practice, SSO doesn’t actually exist for Owner/Admins and, from what I think you’re saying, this is by design. For the few people I have as admins, I will inform them that SSO is a non-functioning service and can be ignored. For Users, I will inform them that they must use two different passwords to authenticate with SSO and unlock their vault with a Master Password.
As we put the service to practice for beta testing, we can explore self-hosting to get around some of the roadblocks that would prohibit the vast majority of our users from adopting it.