RBAC vs ABAC
Role-Based Access Control (RBAC) grants permissions via roles. Attribute-Based Access Control (ABAC) evaluates arbitrary attributes (user, resource, environment) against policy rules.
Role-Based Access Control (RBAC)
RBAC grants permissions by assigning subjects to roles, and roles to permissions. A subject can do anything their assigned roles allow. The evaluation is: "does any of this subject's roles include a permission that matches this resource + action?"
RBAC is simple to reason about, easy to audit ("who has access to what?"), and fits the vast majority of SaaS use cases. Most multi-tenant applications need per-customer roles (admin, member, viewer) with per-resource permissions — pure RBAC.
Attribute-Based Access Control (ABAC)
ABAC evaluates arbitrary attributes of the subject, resource, and environment against policy rules. Instead of "user is an admin," you might write: "user.department == resource.department AND time.hour >= 9 AND time.hour <= 17."
ABAC is more expressive than RBAC but also more complex. It's useful when access decisions depend on contextual data that changes at runtime — for example, a document can only be accessed by users in the same geographic region, determined at request time.
Which to choose?
- Choose RBAC if: you have defined roles, permissions are static (don't depend on runtime data), and "who has access to what" needs to be auditable by humans.
- Choose ABAC if: access decisions require evaluating user or resource attributes at request time, or your policies need to express conditions like time, location, or classification level.
- Hybrid: Use RBAC as the primary model, ABAC for exceptions. Many systems start with RBAC and add ABAC rules incrementally.
WardenAuth's model
WardenAuth implements a hybrid RBAC+ABAC model. Permissions can include optional conditions — recursive AND/OR/NOT rules that evaluate subject, resource, environment, and session attributes at access time (e.g., “allow if subject.clearance ≥ 3 AND environment.ipAddress in 10.0.0.0/8”). Conditions use the AbacCondition type supporting 14 operators (equals, contains, ip_in_cidr, exists, etc.) with field categories for subject, resource, environment, and session contexts. Permissions without conditions always apply; permissions with conditions require the condition to evaluate to true. Use the built-in Condition Editor on any permission to test ABAC rules, and the Access Check simulator to verify policies before deployment.
Related terms
Authorization that evaluates permissions at the individual resource or action level, rather than broadly by user type or role.
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 permission where the resource or action component is *, matching any value. For example, invoice:* grants all actions on invoices; *:read grants read on all resources.