ZAC auth with jwt's or seperate username/password store

Is it possible to somehow seperate zacs username/password from ziti's? Or maybe use JWT(.JSON) auth method for zac?

I want to get rid of username/password auth for ziti and only use jwt based authentication.

Hi @CarlosHleb,

It's not possible to use cert-based auth for ZAC just yet but that's a great suggestion. You can authenticate the ziti CLI using cert/key and in a very recent release (don't recall exactly which) a -f flag was added to the ziti CLI allowing you to use a regular identity file for auth (which is very handy).

Okey, thanks!

Maybe it is possible to only allow to login with username/password(to ziti using cli) from specific IP addresses?

If you have a production deployment of ZAC (not the standalone Node.js server), you can log in with a certificate instead of a username/password. I'll share the steps.

EDIT: documentation preview: Best Practices for Security | OpenZiti

I followed the steps, but it didnt work.

When i try to login i get: Session Expired Your session is no longer valid. Please login to continue. .

  1. Visit the console and allow your web browser to present the client certificate you imported.

What do you mean by this? There needs to be a popup? What does "allow" mean in this context?

EDIT: my ziti version: ZITI_VERSION=1.1.5
zac is on latest

Cert auth works with the console deployment option described in these guides (click on your env: Linux, Docker, Kubernetes), i.e., the "zac" binding in ziti controller config, but not the standalone Node.js server.

When you visit a console single-page application served by the controller's management API, your web browser will prompt you to select the client certificate you wish to present for authentication, assuming you have at least one imported to the client certificate store in your browser.

Potential problems:

  • the console is a standalone Node.js server, not served by the ziti controller
  • the console is behind a TLS-terminating proxy, preventing certificate auth, not a TLS-passthrough proxy
  • the certificate is imported to the browser in a different area than "client certificates"