zeekayandHanzo Dev dc38bfcaff Every caller is a Hanzo IAM identity, and each org reads only its own rows ...

The server authenticates a Hanzo IAM access token natively: on the wire
protocol through the client's existing JWT login, over HTTP as
`Authorization: Bearer`. There is no stored user and no password to share.
The token is verified against the issuer's own keys (OIDC discovery, JWKS
cached, refetched on an unknown kid at most every 30s), for its issuer and
audience, with RS256, ES256 and EdDSA the only algorithms and the key
deciding which. `none` and HS* never reach a key.

The `iam` user directory names an ephemeral user after `sub` and gives the
session, never the user, what the token grants: roles from configured rules
(a program by the application it was issued to, a person, SuperAdmin as
exactly owner == "admin"), and `owner` as the session's organization, which
SQL reads as currentOrg(). It is NULL without one, so a policy written
`USING org = currentOrg()` shows such a caller nothing.

Authorization belonging to the session means two tokens of one subject
cannot meet: named sessions refuse a login with other roles or another org,
query-cache entries are readable only in the org that wrote them, and async
inserts batch and flush per session authorization. A context copy keeps its
external roles, which it silently dropped before on any access recompute.

The image ships the Hanzo rules in config.d and gates on the IAM gtests
(unit_tests_iam) before it is built.


Co-authored-by: Hanzo Dev <[email protected]>

2026-09-24 21:18:11 -07:00

..

0_stateless

…

bugs

…

shell_config.sh

…