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. foo.ziti, 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 media, and
this service is mapped in the bootstrapper config as a vhost, and
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. nginx), and
the API servers are routed to by nginx based on a host header on the incoming request (e.g. api1.example.com, api2.example.com, etc.) and nginx is set up with a wildcard cert so it accepts anything hitting *.example.com
If so, you can leave your single bootstrapper vhost config as is, and then establish Ziti Services for api1.example.com, api2.example.com, etc.
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 Host header.
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.