docs: add notes on ABAC and weakness of RBAC

1 files changed, 27 insertions, 0 deletions

diff --git a/doc/share/authz/RBAC.md b/doc/share/authz/RBAC.md
index e251436..cbf05e0 100644
--- a/doc/share/authz/RBAC.md
+++ b/doc/share/authz/RBAC.md
@@ -65,6 +65,33 @@ 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_.
 
+RBAC makes a decision based on the subject's association with a role. RBAC does
+not easily support multi-factor decisions. RBAC role assignments tend to be
+based upon more static organizational positions, presenting challenges in
+certain RBAC architectures where dynamic access control decisions are required
+(.e.g. `CI_JOB_TOKEN`). Trying to implement these kidns of access control
+decisoins would require the creation of numerous roles that are ad hoc and
+limited in membership, leading to what is often termed "role explosion".
+
+ABAC avoids the need for explicit authorizations to be directly assigned to
+individual subjects prior to a request to perform an operation on the object.
+
+> ABAC: An access control method where subject requests to perform operations on
+> objets are granted or denied based on assigned attributes of the subject,
+> assigned attributes of the object, environment conditions, and a set of
+> policies that are specified in terms of those attributes and conditions.
+
+* Attributes: characteristics of the subject, object, or environment conditions.
+* Subject: is a human or or non-person entity (NPE) that issues access requests
+  to perform operations on objects.
+* Object: a system resource for which access is managed by the ABAC system
+* Operation: is the execution of a function at the request of a subject upon an
+  object. (e.g. read, write, edit, delete, copy, execute and modify)
+* Policy: is the representation of rules or relationships that makes it possible
+  to determine if a requested access should be allowed.
+* Environment conditions: operational or situational context in which the access
+  request occurs.
+
 ## 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)