From 97be97f0e246ef741d3b367e353abe91a67a16ed Mon Sep 17 00:00:00 2001
From: mo khan <mo@mokhan.ca>
Date: Fri, 14 Mar 2025 10:12:12 -0600
Subject: doc: add research on RBAC

---
 doc/share/authz/README.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

(limited to 'doc/share/authz')

diff --git a/doc/share/authz/README.md b/doc/share/authz/README.md
index 6e3cc30..50aeb4c 100644
--- a/doc/share/authz/README.md
+++ b/doc/share/authz/README.md
@@ -68,3 +68,84 @@ The following example allows the subject of the token to read all of the descend
   ]
 }
 ```
+
+## Access Control Models
+
+Access Controls provide a means of restricting access to objects based on the
+identity of subjects and/or groups to which they belong.
+
+### Role-Based Access Control (RBAC)
+
+Assigns permissions to roles, which are collections of permissions related to specific job functions.
+
+This style of access control aligns with how humans organize themselves within
+organizations by assigning job functions to roles. This model is simple and
+aligns well with how humans operate within their job function.
+
+This model also helps to align security objectives with higher level
+organizational policy (.e.g. ethics, privacy, administration). This type of
+model requires centralized control and enforcement.
+
+> The act of granting membership and specifying transactions for a role is loosely
+> analogous to the process of clearing users (granting membership) and the
+> labeling (associate operation sensitivities) of objects ... - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
+
+> A role can be thought of as a set of transactions that a user or set of users
+> can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
+
+Roles are group oriented and they provide a means of naming and describing
+many-to-many relationships between individuals and rights.
+
+1. For each subject, the active role is the one that the subject is currently using:
+
+    ```
+    AR(s: subject) = { the active role for subject s}.
+    ```
+
+2. Each subject may be authorized to perform one or more roles:
+
+    ```
+    RA(s: subject) = { authorized roles for subject s }.
+    ```
+
+3. Each role may be authorized to perform one or more transactions:
+
+    ```
+    TA(r: role) = { transactions authorized for role r}.
+    ```
+
+4. Subjets may execute transactions. The predicate `exec(s,t)` is true if
+   subject `s` can execute transaction `t` at the current time, otherwise it is
+   false:
+
+    ```
+    exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
+    ```
+
+Three basic rules are required:
+
+1. Role assignment: A subject can execute a transaction only if the subject has
+   selected or been assigned a role
+2. Role authorization: A subject's active role must be authorized for the
+   subject
+3. Transaction authorization: A subject can execute a transaction only if the
+   transaction is authorized for the subject's active role
+
+Another user of RBAC is to support integrity. One aspect of integrity is a
+requirement that data and processes be modified only in authorized ways by
+authorized users.
+
+The problem of determining whether data have been modified only in authorized
+ways can be as complex as the transaction that did the modification. For this
+reason, the practical approach is for transactions to be certified and
+trusted. If transactions must be trusted then _access control can be incorporated
+directly into each transaction_.
+
+#### See also
+
+* [Role-Based Access Controls](https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf)
+
+### Relationship-Based Access Control (ReBAC)
+
+### Attribute-Based Access Control (ABAC)
+
-- 
cgit v1.2.3