Why is SSO a sign in option when it accomplishes nothing?

Ask the Community Password Manager
,
1

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?

2

Hey @anthony_S123,

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.

3

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.

4

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.

1 Like
5

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.

6

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.

7

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.

8

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.

1 Like
9

We are also very dissatisfied how the SSO is working. We want SSO ONLY! No additional security by Masterpassword or Device Approval.

We are currently using Device Approvals and Support is approving simply every request. So this adds no Security, just waiting time and effort.

The more so as a Browser Update somehow changes the identifier and every browser needs to be re-approved.

TBH, this made us consider deprecating Bitwarden Enterprise again and switching to Keeper. Our users store passwords everywhere and as Bitwarden is complicated for them, our Rollout failed as not even 50% of our users started using it…

10

Hi Dominik,

Your users should be able to self-serve approvals via either the desktop app or the mobile app. Is there something preventing that workflow?

11

A few things here.

Having to have end users approve their sign-ins via Trusted Device is counter intuitive, especially with organizations that are using SSO and some form of MFA such as Duo.

I understand what Bitwarden was trying to accomplish with Trusted Device but it was the incorrect approach especially when it comes to SSO login for enterprises.

Having to have an end user enter their email, password, accept their MFA and then accept their Trusted Device, is just too much for them and makes them more frustrated. There always needs to be a fine balance of security and end user experience. Trust Devices is a horrible end user experience.

Bitwarden published This blog article in 2022. In it, Bitwarden says “Unlike other password managers that have no SSO integration, or that force businesses to use proprietary SSO services and identity solutions, Bitwarden allows companies to unite password management with existing, standards-based identity access solutions” which is now a false statement.

1Password has SSO integration in the way everyone is looking for. Once your vault is setup in 1Password, every time you need to reauthenticate to your vault, the desktop application opens your web browser to your IdP such as Entra ID/Microsoft. You then enter your email, password and MFA if it isn’t already cached in your web browser.

Obviously the architecture behind the scenes is totally different than Bitwarden’s and how they are accomplishing it.

From my view, Bitwarden is combining the user’s personal vault (master password needed for decryption) and the organizations vault as 1 total vault. I think Bitwarden needs to “break” these vaults in to 2 separate vaults. Where you can use true SSO with your preferred IdP to unlock the organizations vault. Then if the user wants access to their personal vault, they have to enter their master password.

Obviously there is going to be much more involved but as it stands today, if you have an organization that is cloud hosted and want to use SSO login, the login experience is a horrible experience for the end user. As a software company, Bitwarden should be thinking of this.

12

A user only needs to approve the trusted device once - the first time it’s used. It’s the same at 1Password, but they require what they call Linking to get that done.

As to 1Password, take a look a their explanation of the security here: About 1Password Unlock with SSO security and also the onboarding process here: Best practices for using 1Password Unlock with SSO.

Bitwarden has some plans on making the sign-up process for Login with SSO much smoother - including approving new devices from a logged-in web app.

13

Hi Ryan,

this never proofed to be true for us: “When you become a member of an organization, the device you log in with for the first time will automatically be registered as a trusted device.”

For most it’s like:

  1. Get your Browser approved
  2. Get your Browser Add-on approved
  3. Get your Windows App approved

Even if I did the Windows App first for them, they needed Admin approval. And Device Approval after that didn’t work in more then 50% of the cases.

We will reduce the number of Bitwarden users to “priviledged users and those who want to use it” and will let the others user the password manager of Edge Browser (only) for our license renewal in January. This will save us about 50% of the licenses and you got another year to fix things. If you won’t manage - we will be gone and migrate to another Password Manager.

I have been in contact with your Marketing, Development and whatsoever in calls where you promised a lot but you have no fixed timelines and a year later our feedback was not implemented. So you got 12 more months, let’s see…

14

Sorry to hear that this hasn’t been working. I’m glad you’re talking to the right people. Right now, the best flow is to join the organization from the mobile app first. After that, then the user can use the mobile app to approve browser, browser extension, and desktop app.

Soon, targeting Q1, an update to the web app will allow devices to be approved from there. Most users create/join accounts from there so then the flow will look like this:

  1. Receive invite, click to navigate to web app
  2. Enter SSO details, be authenticated in web app
  3. User installs mobile or desktop app, uses the web app to approve that device
  4. User installs Bitwarden extension, uses web or mobile app to approve that installation

It’s important to note that if you clear your browser cookies/cache, it loses its trust. Same for wiping the app data from the mobile app or desktop application.

15

This is good to hear. This workflow at face value sounds like a major improvement from the workflow today.

16

@d0m1 , @d0m @MFKDGAF

This feature is now live! Users can now approve new devices from the web app. The steps I listed above will give the smoothest onboarding experience.

It is possible to approve the extension straight from the web app, however a bug exists where if the extension window closes it loses its place in the process - you can open a second window in Chrome or use the Firefox sidebar to keep it persisting.

17

Maybe I am missing something but this did not work for me. Below is the workflow I used.

  1. Opened Edge.
  2. Bitwarden extension installed via GPO.
  3. Entered my email and checked the box to remember me and clicked continue.
  4. Clicked Enterprise single sign-on.
  5. Web browser opens, I enter my SSO identified and click the Log in button.
  6. Web page takes me to my organization’s federated sign in page (Keycloak using AD credentials).
  7. I sign in, web page takes me back to Bitwarden and the Bitwarden extension pops out in to a new window asking me for my Duo authentication. I click the Launch Duo button.
  8. New tab openes with Duo Universal Prompt.
  9. I accept Duo prompt on my phone.
  10. Duo page goes back to Bitwarden saying I can close the tab that i was successfully logged in.
  11. Go to extension and extension wants me to enter my master password.

I tested this on my web vault and same thing happens. After successfully signing in, it wants me to enter my master password. If this is expected, then I question what the point is of having the Enterprise single sign-on becasue when I log in with my master password, I will be able to see the organization.

18

Do you have SSO with trusted devices turned on, or just regular Login with SSO? It’s a separate option. If you do, you should see a window saying “Login initiated Device approval required.”

19

I knew I was missing something. It was the button to enable Trusted Devices.
I was looking for it under Policies but figured Bitwarden got rid of it.

As a suggestion, I would move the Member decrpytion option out of the Single sign-on settings section and make it its own policy.

When I think single sing-on settings I think of the OIDC or SAML configuration, not how to decrypt a vault.

image
image930×154 15.1 KB

Also, it feels a bit redundant to have to go in to Settings > Policies and enable the Require single sign-on authentication policy and then check a box in Settings > Single sign-on to Allow SSO authentication.

I feel like the Allow SSO authentication setting should be in the Require single sign-on authentication policy

image
image1118×678 73 KB

image
image1212×602 63.9 KB

20

Glad you found it, and thanks for the feedback. I passed it along!