Enhancement: Zero Trust Private Network Access Support

Feature name

  • Enhancement: Zero Trust Private Network Access Support

Feature function

Hi,

It would be very good from a security standpoint to support the use of these types of services, example includes:

  • Cloudflare Access
  • ZScaler Private Access
  • Azure Active Directory Application Proxy — included at no additional cost in AAD P1 licence.

Benefits

Some of the benefits of these products include:

  • Application firewall with authentication.
  • Bot/Crawler protection for the origin/bitwarden server.
  • Attackers would’ve to pass through robust security even before sending/receiving a byte from the origin/bitwarden server, let alone attempting to login or register.
  • No need to expose Inbound ports on the origin/Bitwarden server.
  • For legitimate users, it should just be a single additional click to authenticate with their SSO IdP, which they’ll be doing in Bitwarden as well anyway.
  • Mostly no additional cost for the users/businesses. Small entities could use Cloudflare Access for free. Large entities most likely already have at least one of the above products.
  • None of the above services are known to charge for bandwidth

These products are used by small entities and corporations alike. Especially given that Cloudflare Access is currently free for 50 users, and AADAP is included in P1 licenses.

Potential solution

The above services should already work well with Bitwarden Web Vault.

However, the other Bitwarden client applications would need to be modified to facilitate such services.

  • The client applications might have to add support for web-based authentication as opposed to what currently seems to be form-based authentication only,
  • or OAuth 2.0 authentication support.

Related topics + references

Update on this:
I’m trying to configure Bitwarden with Cloudflare Access.

Findings:

  1. Works fine on the Web Browser and Browser extension
  2. Has issues in the other Bitwarden applications as they aren’t aware of and do not send the CF_Authorization Cookie.
  3. Bitwarden for Windows takes the user to the browser correctly and passes through Cloudflare Access. Understandably, Bitwarden Desktop was not able to navigate to vault.domain.com/identity/connect/token as it hadn’t sent the CF_Authorization Cookie.

Potential solution

  1. For Bitwarden GUI Clients: When users click the ‘Enterprise Single Sign-on’ button, it should navigate within the app/in another window within the app (the app itself is wrapped with a web browser anyway and mostly has HTML, CSS and JS), as opposed to launching a web browser. That way, it’ll have the cookies that are associated with the domain.
  2. For Bitwarden CLI Clients: Before the user is redirected from vault.domain.com after authentication to localhost:randomPort address for the CLI, a javascript on the vault.domain.com page should POST the cookies to the localhost:randomPort for it to be available on the CLI to pass on with the sessionid. This solution could work for the the GUI as well.

Hope to see this become a reality sooner than later.

I’d also very much like to see this feature! The restriction of the GUI clients not able to handle the redirection has also stopped me from using Cloudflare Access.

What could also be an option is that the Bitwarden GUI clients could offer the possibility to manually add HTTP headers that are sent with each request.
For example, Cloudflare Access offers Service Tokens in the form of HTTP Headers that would allow the GUI Clients to bypass the Web-based authentication.
While this might be less secure than if Bitwarden would support the Web-based Authentication (explained by @haneef95), I think it would still be more secure as without because an attacker would have to sniff the HTTP Requests in this network to get the token. And even if the attacker gets the token, he would get as far as what we currently have without the extra authentication, so no loss and probably way easier to implement.

1 Like

Yes, should be fairly easy to implement, I was surprised that it wasn’t implemented with the Enterprise SSO option. It just needs to transmit all the cookies for the vault.domain.com onto the app, which the app would carry on sending to the server for subsequent requests.

Many Enterprises actually use these types of Authenticated Reverse Proxies for all internal apps.

I would appreciate if, someone familiar with the client codebase on Github could submit a PR with these? :slight_smile: