After playing with BrowZer, I have a few questions I was hoping someone could shed light on:
- What are the best practices when it comes to user management?
I guess that due to the zero-trust nature, we need a distinct identity ("key") for every device a user may have. In this case we also had to create an identity to map the user's external auth provider.
This seems to complicate the ability to simply say "user X is allowed to access service Y", which becomes "user X's identities iphone,laptop,browzer are allowed to access service Y".
The user we created in the BrowZer setup guide was not enrolled anywhere - why is that?
When defining BrowZer vhosts, there's no way to define an intercept address. In my case I have a service with multiple intercept addresses which are forwarded to a reverse proxy, so this setup doesn't seem to work with BrowZer unless I split everything to separate services.
Not for BrowZer. Client identities are configured via External JWT Signers | OpenZiti, and the same user (as authenticated by the IdP) can user browsers from multiple devices (iPhone, laptop, etc).
When defining BrowZer vhosts, there's no way to define an intercept address.
We should verify with @curt , but in addition to the configured vhosts, BrowZer will respect other interpcepts that are configured for the service based on Service Policies configured
What I meant was that I have a single service, say,
media that has multiple intercepts, e.g.
bar.ziti. Each of the intercepts will end up hitting the same hosted reverse proxy which will serve different services based on the HTTP
Host header. With BrowZer you cannot choose a specific intercept address to use -- it always seems to pick the first one (
foo.ziti service will always be returned).
@mvelbaum Let me read this back to you to make sure I understand your env/needs:
- you have a "dark" web app you want to protect/access via browZer, and
- this web app is represented by a Ziti service named
- this service is mapped in the bootstrapper config as a
- this web app, once loaded into Chrome, will make requests to multiple other servers, and
- these additional API-servers are placed behind a reverse proxy (e.g.
- the API servers are routed to by
nginx based on a
host header on the incoming request (e.g.
api2.example.com, etc.) and
nginx is set up with a wildcard cert so it accepts anything hitting
If so, you can leave your single bootstrapper
vhost config as is, and then establish Ziti Services for
Once these additional services exist in the network, as well as any necessary policy attributes to authorize the Ziti browZer Identities that need to access them, then the Ziti BrowZer Runtime (ZBR) will see HTTP requests that are targeting
api1.example.com, and the ZBR (based on info it obtains from the Ziti Control plane) will know it should route these requests over the Ziti network (instead of tossing it to the internet). Assuming proper termination out of the Ziti network to your
nginx is in place (like it would be for the dark web app), things should work fine.
If your web app makes requests to 3rd-party servers (e.g. Google Analytics, or whatever), then ZBR will understand that those are not mapped to Ziti Services, and thus it will route those requests over the internet.
I have a Ziti service
media that's intercepted by multiple addresses, and is offloaded to a single reverse proxy (haproxy) which forwards the requests based on the
This is just me being lazy since I have 9 addresses representing 9 media-related servers (e.g., eBook reader, torrent client, tv/movie manager, etc..) and I didn't want to create 9 separate ziti services.
So anyone who gets permission to dial
media can go to any of these 9 addresses and it will just work. The problem is that BrowZer seems to automatically dial the first address every time, and there's no way to configure which address should be dialed.
I guess your original assumption is that all addresses are aliases of the same service.
I am not sure how "real" my use-case is, so it is up to you to decide if it's worth supporting something like this.
P.S. This is clearly not a very secure way of configuring it, since technically you could create a TCP connection to one of the intercepts and then manually pass a
Host header that wasn't on the original intercept list.