Guide

Role-Based Access Control

Eden authorization is evaluated after authentication and before a request reaches an endpoint, template, workflow, or gateway. Grants can be applied at organization and resource scopes, with control-plane and data-plane permissions serving different purposes.

Use RBAC For

Controlling who can create, configure, or delete governance resources.
Restricting access to endpoints and approved templates or workflows.
Separating service identities and runtime agents from human users.
Inspecting a caller's effective access before enabling production traffic.

External identity providers supply a caller identity and claims; they do not bypass Eden RBAC.

Auth Groups

Auth groups are organization-scoped roles with user or agent members. The service derives the organization from the bearer token, so requests cannot select another tenant. Group keys are unique within an organization and can be used as stable declarative subjects:

text

GET    /api/v1/iam/auth-groups
POST   /api/v1/iam/auth-groups
GET    /api/v1/iam/auth-groups/{group_uuid}
DELETE /api/v1/iam/auth-groups/{group_uuid}
GET    /api/v1/iam/auth-groups/{group_uuid}/members
PUT    /api/v1/iam/auth-groups/{group_uuid}/members/{member_kind}/{member_uuid}
DELETE /api/v1/iam/auth-groups/{group_uuid}/members/{member_kind}/{member_uuid}

POST /iam/auth-groups is an idempotent upsert by group_key. Members must be users or agents in the same organization; member_kind is user or agent, and PUT membership is idempotent. Nested groups are not supported. Listing and reading requires organization R, membership mutation requires G|C, and deletion requires G|C|D.

Exact Grants

Use auth_group: as the subject on the exact PUT grant routes. Exact writes replace that subject's permission bits and are the stable surface for desired-state reconciliation:

text

PUT /api/v1/iam/control/organizations/subjects/auth_group:research_desk
PUT /api/v1/iam/control/endpoints/{endpoint}/subjects/auth_group:research_desk
PUT /api/v1/iam/control/templates/{template}/subjects/auth_group:research_desk
PUT /api/v1/iam/control/workflows/{workflow}/subjects/auth_group:research_desk
PUT /api/v1/iam/data/endpoints/{endpoint}/subjects/auth_group:research_desk

Control-plane permissions serialize in RCPGDA order; data-plane permissions serialize in rwx order. Use the matching DELETE route to revoke a grant instead of sending an empty permission string.

For a retry-safe automation flow, upsert groups, reconcile member set differences, apply exact grants, verify them with the matching GET routes, then revoke stale grants and memberships.