CYART // SCHEMA · RBAC-ENGINE7 NODES · 6 LINKSDECISIONACTOR · Request — subject, action, resourceACTOR01Requestsubject, action, resourceSERVICE · Decision point — evaluate(…)SERVICE02Decision pointevaluate(…)DATA · Role store — user → roles → permsDATA03Role storeuser → roles → permsDATA · Attribute source — tenant, owner, timeDATA04Attribute sourcetenant, owner, timeDATA · Policy set — ordered, deny winsDATA05Policy setordered, deny winsDATA · Decision cache — TTL 60 s, keyed by hashDATA06Decision cacheTTL 60 s, keyed by hashSTREAM · Allow / Deny — + reason, + obligationsSTREAM07Allow / Deny+ reason, + obligations

Authorisation models: RBAC, ABAC, ReBAC

When roles stop scaling, when attributes get messy, and why Google built Zanzibar. How to pick a model and where the policy engine sits.

● Must know for interviews🔒 PROLesson·26 min read·Intermediate → Staff
authorisationRBACABACReBACOPA

01Three models

✓What you will learn
  • Choose RBAC, ABAC or ReBAC for a given product
  • Place the policy decision point and keep it fast
  • Avoid role explosion and policy sprawl
  • Explain Zanzibar-style relationship tuples
ModelDecision inputShinesBreaks
RBACuser → roles → permissionsInternal tools, small permission setsPer-resource sharing, tenant nuance, role explosion
ABACattributes of subject, resource, action, environmentCompliance rules: region, classification, timeDebuggability; attribute sourcing at request time
ReBACrelationships: user is editor of doc; doc in folder; folder in orgSharing, hierarchies, multi-tenant SaaSNeeds a dedicated store; consistency ('new enemy' problem)
FigA policy decision point with cached decisions
CYART // SCHEMA · RBAC-ENGINE7 NODES · 6 LINKSDECISIONACTOR · Request — subject, action, resourceACTOR01Requestsubject, action, resourceSERVICE · Decision point — evaluate(…)SERVICE02Decision pointevaluate(…)DATA · Role store — user → roles → permsDATA03Role storeuser → roles → permsDATA · Attribute source — tenant, owner, timeDATA04Attribute sourcetenant, owner, timeDATA · Policy set — ordered, deny winsDATA05Policy setordered, deny winsDATA · Decision cache — TTL 60 s, keyed by hashDATA06Decision cacheTTL 60 s, keyed by hashSTREAM · Allow / Deny — + reason, + obligationsSTREAM07Allow / Deny+ reason, + obligations
  • ACTOR
  • SERVICE
  • DATA
  • STREAM
  • Live flow
  • Lookup / async
//The service asks the decision point with subject, action and resource. The engine pulls roles, attributes and relationships, evaluates an ordered policy set where deny wins, caches the decision briefly and returns allow or deny with a reason.

This is an advanced module

Identity & Access Engineering is part of the Pro pass. 1 more section — the deep dives, the final design, follow-ups and the test — unlock with it.

Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.