We have a running Ziti environment with services and we can give and block access to resources based on devices which is amazing.
I am now exploring auth policies and was wondering can we give a jwt of a device ensuring the device is trusted as a primary and then as a secondary check ask for a username and password to validate the user is an authorized user. I see that jwt for device is a primary option and that username and password is a primary option can you have two primaries. I’m just wondering if this a support action if not I can do posture checks
I think I figured it out you do username and password first then a jwt of the device
An identity can have multiple primary authentication mechanisms. Authentication policies (Auth Policies) allow restriction of which primary authentication mechanisms are permitted. One must be used to initiate authentication.
A JWT primary and a username/password secondary is not possible. It is, however, possible to reverse that. Allow a username/password as primary and require a JWT as a secondary.
1 Like
So I could have username/password as primary then as secondary the devices jwt file
From initial testing it looks like the JWT for secondary must come from an external signer which our environment won’t have, I could be wrong about that but my two options when making the auth policy for password are totp or ext-jwt-signer
Ziti doesn’t separate the concept of a device and a person. It generically refers to both as “identities.”
For a JWT to be valid, it must be signed by an External JWT Signer created within Ziti. External JWT Signers also have a configuration to map a claim within the JWT to a Ziti Identity. Primary and Secondary mechanisms need to map to the same identity for authentication to be possible.
To do what you are looking to do, the JWT and UPDB would both need to be for a single identity. You cannot, for example, have one identity for the device and multiple other people log in via different usernames and passwords. You could have one identity representing the device+user, where the JWT is in a user-protected directory, and then they use a username/password to authenticate.
However, if you want to make sure users are logging in on approved devices, JWTs and private keys stored as files are transferable if the user can read the contents of the files. If you want to make sure an identity is being accessed by a specific machine, using hardware-backed private keys for certificate authentication is the safest way.
Now that we have a proof of concept the next goal is to integrate within the network
what that will look like is roughly 2-4 devices shared among 10 users so we are trying to show is that we can validate the device and validate the user using said device. Not all the users will have the same permissions/access but could use any of the devices.
So it sounds like if I create the Users with username and password and assign a cert to them they can move that from device to device
So could I use username and password for authtication and the json file that is created after enrollment.
@cmbryner, I don't know if it's totally clear to me, but you're looking for users, not administrators to have this sort of capability, right? It's an important distinction and I don't think I saw that made? You're not looking to control access/auth to the controller's APIs in this way, you want people using our pre-built tunnelers (Ziti Desktop Edge for Windows/MAC, Mobile Edge, ziti-edge-tunnel), right?
I ask because although the controller API and SDKs support multifactor auth policies in this way, our tunnelers would all need to be updated too. That's on our radar for sure, but it's not implemented yet. So if you're looking to use a tunneler, deploy a JWT, and force that user to auth with user/pwd each time they try to use that tunneler, that feature isn't implemented yet in the tunnelers...
I think we should make that bit clear. 
Are you looking for our prebuilt tunnelers to support this feature? Or are you looking to add it to your own app via our SDKs?
1 Like
I am looking for the prebuilt tunneler to ask the end user for username and password each time they try and use the tunnel. So in our use case and all future use cases we would want to deploy a JWT authorizing the device and everytime the tunnel is used ask for the username and password.
If it is not feature yet I can document that and once it is released we can test it, do you have a timeline when that may be released? just curious we are no where near deployment but just want to get an idea
We don't have a timeline, yet, no. It's not documented that I know of but @andrew.martinez has been doing a bunch of work around these sorts of things and I think the ideas are floating around. I've heard them, but dunno the details (I'm sure he or someone will correct me if I overstep).
Andrew and I did talk about a year ago, about adding basic OIDC flow into the tunnelers. The idea would be that each tunneler would be capable of performing a PKCE-style flow. (nice Auth0 post on PKCE here for those interested).
The gist is that the user would get prompted to open a web page and "login" somewhere via their browser, the server redirects the browser to a server the tunneler is providing and if successful the user logs in. We have another community member that actually did exactly what it sounds like you want, but did it for zssh as a proof of concept. His initial PoC used the jwt for primary auth and OIDC user/pwd for secondary auth. OpenZiti isn't an OIDC provider just yet but that's what I think Andrew is implementing (I think ). Then instead of using some other OIDC provider, you could use OpenZiti for that username/pwd combo...
I'll guess that it'll be sometime early next year just to be totally transparent. This is one of the many features we just need to prioritize. I'm sure we'll get it done but right now all I have is a guess as to when.
We've started the development effort to add support for external JWT signers to ziti-sdk-c. This is a prerequisite for adding the OIDC workflows described above for the tunnelers. Once this work is complete, we'll have a better ETA for adding to the tunnelers.