Commit Graph

3 Commits

Author SHA1 Message Date
unkinben 7610627168 Add LiteLLM RBAC: akP-litellm groups + role claim mapping
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/plan Pipeline was successful
Bring LiteLLM into the two-tier RBAC and map groups to LiteLLM roles.

- akP-litellm-admin / akP-litellm-user permission groups (bound to the litellm
  app for access); added to akR-global-admin / akR-standard-user roles.
- Generic per-provider role_mappings: emit an app role claim computed from
  effective (hierarchical) group membership. LiteLLM: emits `litellm_role`
  (proxy_admin for akP-litellm-admin, internal_user for akP-litellm-user, else
  internal_user_view_only); LiteLLM reads it via GENERIC_USER_ROLE_ATTRIBUTE.

Validated: plan 5 to add, 3 to change; generated role expression renders correctly.
2026-07-19 18:42:36 +10:00
unkinben 805ea48a36 Derive group name from filename; use distinct ak_groups claim
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/plan Pipeline was successful
- Permission/role group name now comes from the config filename (the map key),
  dropping the redundant `name` field from each YAML and the object types.
- The hierarchical mapping emits an `ak_groups` claim (scope `ak_groups`) instead
  of `groups`, so it never collides with the direct-groups the default profile
  mapping already emits under `groups` (Authentik overrides same-key claims in an
  unpredictable order). Apps request the `ak_groups` scope and read that claim.
2026-07-18 16:19:34 +10:00
unkinben 1dab2ecc6f Add two-tier RBAC: permission/role groups, access policies, group claim
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/plan Pipeline was successful
Introduce a user -> role -> [permissions] model for app access and roles,
managed declaratively.

- Permission groups (akP-<app>-<access>) under config/permissions/: atomic units,
  each names the application it grants access to.
- Role groups (akR-<role>) under config/roles/: what users are assigned to;
  each nests permission groups via parents (akR-global-admin -> all *-admin,
  akR-standard-user -> all *-user). Split into a separate authentik_group
  resource so roles can reference permission ids without self-reference.
- Policy bindings gate each application to its permission groups (and, via
  child->parent membership propagation, the roles that nest them).
- Hierarchical `groups` scope mapping: walks user groups up through .parents so
  the OIDC claim includes inherited permission groups (works around
  goauthentik/authentik#15579). Inert until a provider requests the `groups`
  scope, so no behaviour change to existing apps until they opt in.

Validated with `tofu validate`.
2026-07-18 16:11:39 +10:00