Keeping IDP Dark

BrowZer
1

Hey All,

Wondering if i could get some architectural on if it's possible to keep my IDP provider dark while using BrowZer?

Currently for SSO onto the Ziti network, i've got a tunnel on the controller which is tunneling the redirects for my IDP into the LAN where the IDP is hosted,

Now this works fine for users connecting to the Ziti network and signing up, and admins accessing Zac. However, due to the way that BrowZer works from my understanding, it doesn't touch the Ziti network untill it's authenticated with an IDP then it passes information on via Ziti however when the issuer address is dark and not publically accessible this breaks that chain.

I have had a couple ideas that i think might work here but wanted to see if there was anything i might be missing here,

  1. Zitifed caddy proxy on the controller intercepting the issuer address which is then proxied to use the current service configured to allow SSO to work (The one intercepting the re-directs)

  2. Zrok public share as the "issuer" address so that when Browzer tries to connect its essentially tunneled to the IDP app. Which is kind of doing the same as the caddy proxy.

The goal here is to keep everything dark essentially while still utilsing the functionality offered,

Thanks,
C

2

Hi @Curt_Ziti,

With any OpenZiti ext-jwt-signer auth, I don't think there's any creative ways to successfully keep the idp dark. This is not BrowZer-specific btw, this would be true for OpenZiti tunnelers as well, but with tunnelers there's a second-identity option available. Basically one identity is secured only by a ziti identity only (no IdP) and provides the IdP as a service, then there's the second identity that IS ziti + idp which provides all the other services. BUT that defeats the whole purpose of BrowZer so for BrowZer, I don't think it's possible.

Both the options you presented are effectively "public" options and by definition, not dark. I could see some people consider it a bit more secure insofar as both options require the proper http Host header to be supplied to the endpoint to be tunneled correctly (as opposed to the services being exposed on an IP address that is scannable).

I haven't tried either of your options, off the top of my head I'd think they would both work but I've not tried it to be sure.

Let us know what you come up with :slight_smile: