iam

Overview ¶

Package iamsvc folds Hanzo IAM into the unified hanzoai/cloud binary as an in-process subsystem (HIP-0106) — the LAST binary-consolidation piece: "one Go binary (hanzoai/cloud) embeds IAM + KMS + o11y".

WRAP, DON'T REWRITE. IAM is a Beego app (~150 routes registered in hanzoai/iam/routers.InitAPI over controllers.ApiController/RootController). iamserver.InitEmbed() runs the ENTIRE IAM identity runtime — config, SQLite store, KMS signing keys, controllers, authz filters, background sync/monitor loops — as an in-process embed: it is standalone iamd's bootstrap MINUS the standalone-daemon side effects that would crash or endanger this shared process (no StopOldInstance `lsof`/SIGKILL, no LDAP/RADIUS listeners, no export/os.Exit), binds NO HTTP listener, and RETURNS AN ERROR instead of panicking. (The standalone `hanzo iam` / iamd path still uses iamserver.Init + web.Run, byte-for-byte unchanged.) After a successful InitEmbed the full IAM http.Handler is web.BeeApp.Handlers; this subsystem mounts THAT verbatim on cloud's shared zip.App at every path prefix IAM owns. No auth logic is reimplemented — the same controllers answer, so hanzo.id's OAuth/OIDC semantics (authorize clientId org-resolution, JWT audiences, SuperAdmin owner=="admin", argon2id password hashing) are preserved byte-for-byte.

The one hook web.Run() performs that the embed bootstrap omits is Beego session-manager registration; this subsystem fires it explicitly (initSessions), mirroring the sanctioned iam.Embed path, else every session-touching request (login, authorize) nil-derefs in the router.

FAIL-CLOSED, NOT FAIL-LOUD. A broken/misconfigured IAM does NOT crash the consolidated binary: InitEmbed's error (or a session/handler failure) degrades THIS subsystem to a 503 fail-closed on every IAM prefix (mountFailClosed) while every co-resident subsystem (KMS, o11y, …) stays up — the blast-radius isolation the whole consolidation exists for, mirroring the KMS "no master key → health-only" pattern.

Mounted in-process (whole Beego handler, full request path preserved):

/v1/iam/*      API + OAuth (/v1/iam/oauth/{authorize,token,userinfo,introspect,
               revoke,...}) + OIDC (/v1/iam/.well-known/{openid-configuration,
               jwks,...}) + login/logout/signup + userinfo + me/* + cap/* +
               cert/saml/tokens + the full admin surface
/.well-known/* legacy root OIDC discovery + JWKS (relying-party compatibility)
/login/oauth/* browser authorize surface (the /v1/iam/oauth/authorize 302 target)
/_/iam/*       login UI SPA assets
/cas/*         CAS 1.0/2.0/3.0 ticket validation
/scim/*        SCIM 2.0 user/group provisioning

STAGING (security-critical): activation is the standard enable-list gate — the operator adds "iam" to the cloud deployment's --enable only AFTER IAM's config (Beego app.conf + env + KMS signing keys) is present in the cloud runtime and the fold is verified (login/authorize/token/jwks + the operator SSO chain). Until then hanzo.id is served by the standalone iam pod via ingress. A cloud pod that enables "iam" MUST run at replicas=1 (Config.Validate enforces this): IAM's session store is Beego's process-local "memory" provider, so a horizontally scaled app tier would mint a login/authorize session on one replica and lose it on the next. If a broken config slips through, the subsystem serves 503 fail-closed (above) rather than crashing cloud.