Access Policy
A binding between a subject (user or service) and one or more roles within a scope. Defines what the subject can do in that tenant context.
An access policy in WardenAuth is a binding between a subject (a user or service identity) and one or more roles within a specific scope (tenant workspace). It answers: "what can this subject do in this tenant context?"
Structure
// POST /v1/scopes/:scopeId/access-policies
{
"subjectId": "user-abc123", // Cognito sub, Auth0 user_id, or any string
"roles": ["admin", "billing-viewer"]
}A subject can hold multiple roles within a scope. Permissions from all roles are evaluated together (with deny-wins semantics for conflicts).
Scope isolation
Access policies are scoped. The same user can be an admin in one workspace and a viewer in another. The scopeId in the has-access check determines which access policy is evaluated:
// User is admin in workspace A, viewer in workspace B
// These evaluate different access policies:
{ subjectId: "user-123", scopeId: "workspace-a", resource: "invoice", action: "delete" }
// → allowed (admin role)
{ subjectId: "user-123", scopeId: "workspace-b", resource: "invoice", action: "delete" }
// → denied (viewer role)Related terms
Role-Based Access Control (RBAC) grants permissions via roles. Attribute-Based Access Control (ABAC) evaluates arbitrary attributes (user, resource, environment) against policy rules.
An authorization evaluation rule where an explicit deny on any matching permission overrides all allow permissions. Used to enforce least-privilege without restructuring role hierarchies.
A logical isolation boundary in a multi-tenant system. Permissions, roles, and access policies in one scope are completely independent from those in another.