Relationship-based access control

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Citation bot (talk | contribs) at 08:41, 16 November 2022 (Alter: title, url. URLs might have been anonymized. Add: authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox2 | #UCB_webform_linked 2008/2778). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


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

  1. ^ "RDF 1.1 Primer: Triples". www.w3.org. Retrieved 2022-07-07.
  2. ^ 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.
  3. ^ a b Gates, Carrie (2007). "Access control requirements for web 2.0 security and privacy". IEEE Web. 2: 12–15.
  4. ^ a b "Authorization - OWASP Cheat Sheet Series". cheatsheetseries.owasp.org. Retrieved 2022-06-21.
  5. ^ 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