Question on ZDBC and MFA (under Posture checks). My understanding is that posture checks is within the OpenZiti SDKs (not, could not find a great link in documentation to these), therefore, could you invoke MFA via a popular 3rd party app when using zitified JDBC (i.e., not running ZDE)?
Zitified JDBC isn’t really enough for me to have an answer. My instinct though, is “probably not”. I think trying to use MFA with ziti and JDBC will be exceptionally difficult. The challenge will be in the lifecycle if the of the connection. When you use MFA you need to be able to respond to events, show the user a dialog for digits etc.
Since you mentioned “3rd party app” that sort of UI and experience are probably not going to be under your control. Feels like it’ll be a difficult thing to accomplish. I could be wrong, but that’s my inclination.
You enable MFA for an identity “from the identity”. For example, on the latest ZDE for macOS (2.22), if MFA support is enabled (Advanced Settings/Enable MFA), a toggle appears for each identity that allows you to turn MFA on for that identity (a QR code presented that can be scanned by your TOTP application, e.g., Google Authenticator). ZDE for Windows has a similar workflow. Passing MFA is then required as a secondary authentication check before this identity can list/access any services.
MFA posture checks are additional authorization checks that can be centrally configured for services, and require MFA to be enabled and passing for an identity to access these services. These posture checks can also require MFA to be re-checked on wake, unlock, and/or after a configurable period of time.
MFA posture checks are configurable in ZAC under MANAGE IDENTITIES submenu “Posture Checks”, of type “Multi Factor”.
Nice! I think the posture check you want (if you want additional checking of MFA for access to specific services) is the one of type “MFA” (called “Multi Factor” in ZAC).
Yes, the MAC address check is an additional layer of security, and it is vulnerable to MAC spoofing. The Process checks are more difficult to defeat as signing footprints can be configured and checked (so an attacker replacing the executable will be defeated).
The value of the MAC check is that it could save the day if your key and cert are compromised, but the attacker doesn’t know what to use for a valid MAC address. It’s not as strong as the other auth & policy checks and relies on some “security through obscurity” (and knowhow on the attacker’s part), but we had people request it, even knowing this limitation.
When configuring a Process check, in addition to the path of the executable, you can specify a SHA512 hash to verify the executable is what’s expected, or you can specify the signer’s certificate fingerprint to verify the executable was signed by the expected entity.
Here’s an example of getting the signer fingerprint on macOS using either codesign or OpenSSL:
Right… so looking at this and other posts, its possible from the SDK but it need to be managed and configured. Today this is done via the tunneler; if I embed it in my application running on the endpoint then my application needs to handle this function, the events and dialog etc.
Authentication policies have the ability to require TOTP MFA. The default authentication policy in a ziti network does not require it, but it can be turned on. Existing clients with auth policies that require MFA TOTP will have the ability to enroll while partially authenticated (i.e. passed cert/jwt/updb auth but not TOTP MFA).
auth policies can require MFA TOTP during authentication (i.e. logging in)
clients can always decide to have MFA TOTP for authentication regardless of auth policies
MFA posture checks can require MFA TOTP during authorization (i.e. creating service sessions/connecting)