ABAC
Attribute-based access control: granting access from identity and resource attributes rather than static role membership.
ABAC grants access based on attributes, department, location, clearance, resource sensitivity, evaluated by policy at decision time, complementing role-based access.
- ABAC uses attributes, not fixed role membership
- Decisions evaluate identity + resource + context
- More dynamic and fine-grained than RBAC alone
- Often combined with RBAC in real deployments
Attribute-based access control (ABAC) grants access by evaluating attributes, of the identity, the resource and sometimes the context, rather than by static membership in a role. Where role-based access control asks "which roles does this person hold?", ABAC asks "do this person's attributes satisfy the policy for this resource, right now?"
A concrete example
Consider the rule: grant access to the EU Finance reporting app if department = Finance AND region = EU AND employeeType = Employee. Nobody is added to a group by hand. The moment an identity's attributes match, access is granted; the moment they stop matching, for example the person transfers out of Finance, access is removed automatically. That dynamism is ABAC's great strength.
ABAC versus RBAC
| Dimension | RBAC | ABAC |
|---|---|---|
| Basis of decision | Role membership | Attribute values and context |
| Adapts to change | Manual role reassignment | Automatic as attributes change |
| Auditability | Very clear (who is in the role) | Requires evaluating the policy |
| Best for | Stable, well-understood job functions | Fine-grained, context-sensitive access |
Neither is "better". RBAC is transparent and easy to certify but rigid; ABAC is flexible and self-adjusting but harder to reason about and audit. Mature programmes use both.
How SailPoint implements ABAC ideas
IdentityIQ does not have a separate "ABAC engine"; instead it expresses attribute-driven access through mechanisms you already use:
- Role membership criteria: an assigned role can attach automatically to any identity whose attributes match a defined condition. This is ABAC producing an RBAC assignment, the best of both.
- Assignment rules: BeanShell logic that evaluates identity attributes to decide role or entitlement assignment.
- Provisioning policy and forms: attribute values can drive what gets provisioned and how account attributes are populated.
In Identity Security Cloud the same idea appears as access profiles and roles with identity-attribute-based assignment criteria.
Designing good attribute-driven access
- Trust your attributes first. ABAC is only as good as the authoritative data behind it; dirty HR data produces wrong access instantly and at scale.
- Keep policies readable. Deeply nested attribute conditions become impossible to audit; prefer a few clear criteria over sprawling logic.
- Combine with RBAC deliberately. Use ABAC to drive automatic role assignment rather than granting raw entitlements directly, so you keep the auditability of roles.
Common pitfalls
- Attribute drift: if HR attributes lag reality, access lags with them, granting or revoking at the wrong time.
- Over-engineering: not every grant needs to be dynamic; static roles are fine for stable functions.
- Hidden logic: attribute rules buried in code are hard to govern; document the intent of every rule.