Relationship-based access control
 | This article, Relationship-based access control, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
| This article, Relationship-based access control, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
In computer systems security, Relationship-based access control (ReBAC) defines an authorization paradigm where a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources.
In general, authorization in ReBAC is performed by traversing the directed graph of relationships. The nodes and edges of this graph are very similar to triples in the Resource Description Framework (RDF) data format[1]. ReBAC systems allow hierarchies of relationships, and some allow more complex definitions that include algebraic operators on relationships such as union, intersection, and difference.[2]
ReBAC gained popularity with the rise of social network web applications, where users need to control their personal information based on their relationship with the data receiver rather than the receiver’s role.[3]
In contrast to role-based access control (RBAC), which defines roles that carry a specific set of privileges associated with them and to which subjects are assigned[4], ReBAC (like ABAC[5]), allows defining more fine-grained permissions[4]. For example, if a ReBAC system defines resources of type document, which can allow one action editor, if the system contains the relationship ('alice', 'editor', 'document:budget'), then subject Alice can edit the specific resource document:budget. The downside of ReBAC is that, while it allows more fine-grained access, this means that the application may need to perform more authorization checks.
ReBAC systems are deny-by-default, and allow building RBAC systems on top of them.[2]
History
The term ReBAC was coined by Carrie E. Gates in 2006.[3]
In 2019 Google published a paper presenting "Zanzibar: Google’s Consistent, Global Authorization System".[2] The paper defines a system composed of a namespace configuration and relationship data expressed as triples.
Since the release of that paper, several companies have built commercial and open source offerings of ReBAC systems.
See also
References
- ^ "RDF 1.1 Primer: Triples". www.w3.org. Retrieved 2022-07-07.
- ^ a b c Pang, Ruoming; Caceres, Ramon; Burrows, Mike; Chen, Zhifeng; Dave, Pratik; Germer, Nathan; Golynski, Alexander; Graney, Kevin; Kang, Nina; Kissner, Lea; Korn, Jeffrey L. (2019). "Zanzibar: Google's Consistent, Global Authorization System". 2019 USENIX Annual Technical Conference (USENIX ATC '19). Renton, WA.
- ^ a b Gates, Carrie (2007). "Access control requirements for web 2.0 security and privacy" (PDF). IEEE Web. 2 (0): 12–15.
- ^ a b "Authorization - OWASP Cheat Sheet Series". cheatsheetseries.owasp.org. Retrieved 2022-06-21.
- ^ Hu, Vincent C.; Ferraiolo, David; Kuhn, Rick; Schnitzer, Adam; Sandlin, Kenneth; Miller, Robert; Scarfone, Karen (January 2014). "Guide to Attribute Based Access Control (ABAC) Definition and Considerations". NIST. doi:10.6028/nist.sp.800-162. Retrieved 2022-07-07.
External links
- Introduction to Authorization and OpenFGA
- Relationship-Based Access Control (ReBAC)
- AuthZ: Carta’s highly scalable permissions system
- SpiceDB is the open source Zanzibar-inspired database that stores, computes, and validates fine grained permissions.