Can I configure sharing rules for my installed identities or are they the same for everyone that uses this computer? For example, child or gaming desktop user on the same laptop where I have installed work identities in the work user’s desktop.
At this time, the Ziti Desktop Edge for Windows (ZDEW) does not allow for sharing rules. The ZDEW relies on being able to create a network interface. That action requires elevated privileges. In order for ‘any user’ to use the ZDEW you must run the installer as admin, which subsequently installs a service that runs as the system to do these sorts of operations for “non admin users”.
What that ends up with - at this time - is all the identities added to a system are accessible and stored by the “system” in the system’s profile.
We have thought about allowing individual users to specify their own identities but it’s not an option at this time. I would not be surprised to see us support both shared and per-user identities in the future, but for now it’s only ‘shared’.
Hopefully that’s enough detail but if you have more questions - lemme know
1 Like
That answers my question completely. Thank you. Now that I think about it, this is also true of the Linux tunneler. Not unique to Windows. Identities may not be readable by all users, but when an admin runs the tunneler all the loaded identities’ services become available to all users and all processes. It’s a per-device configuration, not per user, generally speaking.
is it on the roadmap to make the identities user based?
Kind of a security problem (at least for my environments) to have anyone who can access the device have access to all identities.
It is not on the roadmap. Tunnelers are purposefully bridging the zero trust network with IP. Anyone on the machine can send traffic via that bridge. To my knowledge, there's no way to establish a device that only a certain user can send traffic to. This (again to my knowledge) is not a problem unique to OpenZiti either. This is how every VPN/zero trust overlay works that bridges IP. OpenZiti's application-embedded approach is superior here. If applications integrated OpenZiti into the app itself, this would not be the case, but that would also not be a situation where there is a purpose-built application trying to bridge a zero trust overlay with the inherently trusted IP underlay.
An improvement I might suggest would be to use a security setup that is "device + human". You enroll the device and provide it an identity as always, but in order to access services you enforce a secondary form of authentication. Until recently, that would be done with a TOTP code but now you can layer on external jwt signers if you want. You can create an authentication policy that uses certificates for "primary" auth, and TOTP or ext-jwt-signers for secondary auth and achieve the "device + human" combination. Then it's not any human, it'd have to be "properly privileged" humans.