I watched the most recent Ziti TV and was really impressed… nice work guys… it is really exciting to see how far you have come 
After watching the demo, the Golang JWT chat example looks like its something I need to get my teeth into… I am considering the Oracle IDCS solution to act as the IdP… which should work in a similar manner.
One thing that I want to have a better understanding before I start this journey is the broader context… as I am still learning a lot of things around security tokens etc.
From what I have picked up… the ziti external signers are a recent addition (sorry if they have been around for a while)… and provide a link between an IdP… and a private Ziti end point (ztha) or identity (ztaa).
I also remember a mention about Browzer… of which… its this capability that allows a website to interact natively with ziti end points…
If possible… it would be great if you can provide a helicopter description of what is going on… as it will help me navigate how to get this going… and identify all of the new things I need to learn.
I am very excited about this…
The helicopter-view of what's going on here is that we have two instances of our sample application which is able to connect to the overlay without having been "enrolled" in the 'usual' way. Meaning, instead of delivering a jwt to a client and having that client run an 'enrollment' of some kind, the application can instead rely on an external IdP. The IdP provides a token (a jwt) back to the app/the golang sdk which is then used to authenticate to the overlay.
External jwt signers have been supported in the controller for a while but they aren't supported in all the sdks yet (golang was the latest one), not supported in the tunnelers (no plans to enable it there just yet). There's also not much in terms of samples/guidance/doc yet. That just means attacking this right now will likely be pretty tough. Ext-jwt-signers were developed to support Browzer which was the first client using them.
Personally, I've been reading as much as I can about things like OAuth 2.0 flows and OIDC Connect. I'd just really dig into that, then go back and watch the video and a lot more will probably make sense.
1 Like
Thanks… that fills in a few gaps… especially when you mentioned that it avoids the need to deliver a jwt to a client to then run an enrolment process.
So… if we use this approach… the point of weakness then becomes the IdP…
I get it now… very helpful
@TheLumberjack I was thinking about this overnight and have one more question.
In the case of a host, I am assuming that it will still require an enrolled identity… and the external signers are only for clients.
Is this correct?
Not sure what you mean by “a host” but I wouldn’t think it would matter. The ziti tv demonstrates two clients, both are simultaneously dialing a service, and binding the same service. The tunnelers aren’t enabled with it yet so if that’s what you’re thinking?
1 Like
That makes sense … I was not 100% familiar with that demo… which is really helpful for me to know where to start.
The reason for the question was to think of a broader context… where say… I have an eCommerce website… and an online user wanting to process a transaction.
Say for instance… the eCommerce website uses the ziti SDK… meaning that its only accessible over the overlay network via dialling an identity
… does this mean the server identity could be an identity in the OIDC… where the server identity does not need to be manually enrolled on the server?
or… does this only relate to the client identity that is required process the transaction…
PS… I am thinking that as I progress my journey with this… I will keep track of my steps and summarise them into a working document.
At this stage… I am targeting the architecture to understand how it all fits together
Hard to say for sure without understanding all the entire flows. I don’t think there’s any limit as to where the identities are. I would say though that it’s not “just for clients”.
1 Like
I find this very interesting.. I am definitely going to explore this in a lot more detail..
To dig into this a bit more.. say for example the zitified ssh client.. which requires a ziti ssh server.
My understanding is that we can theoretically store the server and client identity in an OIDC IdP... though we would still need a local private key
Am I understanding this correctly?
I just want to be clear around the limitations / configurations... as this is a pretty huge capability to now have access to.
I think I get this now… as you still need to create the identities in the controller… it’s just that you don’t enrol them…
This is the point of the external signer… which uses the IdP to facilitate the identification.
Not 100% sure yet how a server identity would be used in an IdP… as it does not have a password to authenticate itself… whereas… a client would.
Is this correct? I look forward to your further comments… especially how a server identity would engage with an IdP… I find it totally fascinating.
Read up on the various OAuth flows and I bet you'll find one that would cover this situation. It's not particularly surprising, it's just more of a "client/client secret" type of flow and it's exactly what Andrew and I demo'ed... Remember, both of those programs we ran are running as a server, and a client.
