I found https://community.bitwarden.com/t/withdrawn-do-not-mandate-use-of-the-master-password-for-webvault-login/15028 but still not quite sure if or how to implement this?
When enabling SAML / SSO with MSFT/Azure, the user is prompted for their Microsoft credentials + any 2FA associated with that. Upon successful authentication, they are then prompted for their Bitwarden Master Password.
Is there any way to bypass that 2nd step (MP) and rely only on the IdP to unlock the vault?
This is on our radar - it’s tricky to do without one system (Bitwarden/IdP/middleware) having a path to deriving the encryption keys. Not impossible, but it’s not normally how zero-knowledge + E2EE usually operates 
@tgreer I understand (I think) that never being able to decrypt with anything but the master key is more secure. I personally would never trust my vault to a 3rd party either, but… some businesses demand functionality like this and are willing to accept the compromise. So, glad to hear it’s on the radar. Thanks!
I am a huge proponent of OSS and have shouted the Bitwarden name from all rooftops, converting family and friends to this great tool (ctrl+shift+L traversing a list of logins was my big feature request early on that has really revolutionized my usage).
I just had an enterprise client that was using LastPass for all of their users/teams. I talked with them about switching, and after testing, they agreed that they really liked the interface. We implemented SSO with their Azure AD as IdP – as soon as they saw a Master Password was still required, they asked to switch back to LastPass, which they have now done. As an MSP, I like to see the client happy with a solution, so that was the best move.
As a manager for several different software development teams that work in the healthcare space, I understand why this is tricky, but it is also necessary. I hope this can be moved up the priority list. Having SSO but still needing a separately managed password is counter intuitive.
Am I safe in assuming that LastPass has sacrificed security for convenience with this SSO feature where they do not require an additional “vault” password for decryption?
We’ve actually released an option for this (currently available for self-hosted instances) - it’s called Key Connector.
This allows the company to leverage SSO without a master password.
Managing keys is incredibly important and we highly recommend this only be deployed by those who have comfort and experience managing mission critical security infrastructure.
With that said, give it a look! Hopefully it solves your customer’s request 
Hey Trey – thanks for the quick reply here. We did look at Key Connector, and we heavily evaluated whether or not that was a direction they wanted to go. However, they were strongly opposed to adding more infrastructure for password vault management. They like the idea of backup and DR being managed by the Bitwarden teams vs us/them, since that would become one more point of failure. Additionally, they like knowing that even if their office/server infra loses Internet, they can still access their password vaults.
While the Key Connector is an option for some, I wouldn’t call it a complete solution. It is one option, but needing to take all of the Bitwarden vaults in-house isn’t ideal as an only option. I can’t imagine they/we are the only clients that feel this way, especially with more and more migration to the cloud.
I completely agree with you @RPC. I have been trialing the Enterprise version of Bitwarden for the past few days for my organization. I love the product but I already know that I am going to have a difficult time selling my leadership on this tool due to SSO still requiring an additional master password for every user to remember. It would be great if we could have a truly SSO option for Azure AD integrations.
We too are currently evaluating Bitwarden and were surprised to find SSO still requires a master password. Hosting Bitwarden isn’t an option for us so this is certainly putting the brakes on what I thought would be an easy move.
has there been any update on this for cloud version?
Hey @joshxcaron, currently Key Connector is only available for self-hosted solutions Deploy Key Connector | Bitwarden Help Center
Hey @Rovert66 for teams that are comfortable with self-hosting keys, we also offer Key Connector.
Key Connector is a self-hosted application that facilitates Customer-managed Encryption, allowing an Enterprise organization to serve cryptographic keys to Bitwarden clients.
Key Connector runs as a docker container on the same network as existing services, and can be used with login with SSO to serve cryptographic keys for an organization as an alternative to requiring a master password for vault decryption (learn more). Bitwarden supports deployment of one Key Connector for use by one organization for a self-hosted instance.
Management of cryptographic keys is incredibly sensitive and is only recommended for enterprises with a team and infrastructure that can securely support deploying and managing a key server.
This is one of our blockers moving from LastPass.
Would rather protect our vaults with existing security controls and key vault provided by auth providers (i.e Azure AD) than self hosted manually via connector.
A half-half key split between provider and bitwarden means any individual service compromise wouldn’t reveal vault contents.
While this is ultimately something I’d love to see also available for the SaaS cloud option (perhaps this request should be “Key Connector for Public Cloud” or something similar) there are a few questions that arise from how the implementation for LastPass is handled.
For me when I am checking the resources provided by LastPass it gives rise to some concern, especially given to light the recent security breaches and how some data is being handled in an unencrypted fashion, I am always wary when there are questions to how software is being implemented.
These are just some the pros IMO of using an open-source, code-audited password manager such as Bitwarden, which has from my experience always had wonderful documentation and transparency when it comes to how they operate.
According to https://support.lastpass.com/help/what-are-the-limitations-for-federated-ad-fs-lastpass-enterprise-users-lp010135 which stipulates
No Offline access – The client side (web browser extension) must remain online in order to obtain the user’s encryption key and unlock the user’s LastPass vault. For this reason, offline login is not available.
Your Welcome email will include your LastPass username (email address) and a temporary Activation code that you will use to log in with (only once) so that your vault can be de-crypted and re-encrypted to utilize your Azure AD, Okta, Google Workspace, PingOne, PingFederate, or OneLogin account going forward.
Your Welcome email will include your LastPass username (email address) and instruct you to log in to LastPass with your current master password so that your vault can be de-crypted and re-encrypted to utilize your Identity Provider (IdP) account going forward.
Step #3: Selected users must log in to re-encrypt their vault with their Azure AD, Okta, Google Workspace, PingOne, or OneLogin
About this task: Users selected for conversion in Step #2 above must log in to LastPass to re-encrypt their vault with their Azure AD, Okta, Google Workspace, PingOne, or OneLogin account, as follows:
The provided documentation provided appears to indicate that the encryption key is stored online either with the IdP (yikes), or with LastPass themselves (which in theory separates the authentication from the encryption) but still gives the keys over to LastPass.
My main question when evaluating any password manager is always who hold the keys and how is that being stored? If I don’t hold the keys IMO I don’t have proper ownership of my private data.
Bitwarden’s documentation on Key Connector gives quite the in-depth dive into the technical processes to separate identity authentication and verification, from encryption/decryption keys while maintaining a zero-knowledge architecture where nobody but you maintain control of your private data and even Bitwarden themselves can never gain access to your data.
Kent you might be interested in this document on the federated login.
The answer is half is stored at LastPass and half with the identity provider. Which either alone, has no use like public/private keys.
Yes, the key is stored with the identity provider which is inherently trusted being an identity provider.
The “master password” upon “federation” then becomes, by its crypto-generated nature, stronger than a typical user password.
Offline has never been a deal breaker for us.
Key connector remains for those who are more comfortable hosting the keys themselves.
@bw-admin 1Password has also just added the functionality for cloud-hosted vault with SSO and no master password. If this is not on your radar, it should be. I just had yet another client pass on Bitwarden because they didn’t want to be prompted for a master password immediately after being prompted for their SSO credentials.
With a zero-knowledge implementation, I know there are complications. Would love to get my clients on Bitwarden, in my opinion the best and most secure option. But this is a blocker, over and over again.
Hey @RPC thanks for the feedback, rest assured I’ve passed it along to the team.
As an MSP/VAR, I will have some clients that will appreciate the extra security, but most will just hate the inconvenience.
This is a really important issue for us; once it’s resolved we plan to implement Bitwarden internally and start selling to our clients ASAP.
Can’t wait for more news on this…
I haven’t completely thought this through but I’m
Wondering if there is a way that the idP can store and pass the master key or a key to unlock the master key.
Probably complicates the idP configuration and may be fraught with some other issue I’m not thinking of
Thanks all the team is working on a masterpasswordless SSO option 
Is there a rough ETA for this? This is the only thing missing before we migrate clients away from Keeper.