directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From smckin...@apache.org
Subject [directory-fortress-enmasse] branch FC-265 updated: Describe arbac02 checks
Date Sat, 16 Mar 2019 15:16:41 GMT
This is an automated email from the ASF dual-hosted git repository.

smckinney pushed a commit to branch FC-265
in repository https://gitbox.apache.org/repos/asf/directory-fortress-enmasse.git


The following commit(s) were added to refs/heads/FC-265 by this push:
     new 600e1bf  Describe arbac02 checks
600e1bf is described below

commit 600e1bf9f08665406023f6cb7b79b738f08d2ed0
Author: Shawn McKinney <smckinney@apache.org>
AuthorDate: Sat Mar 16 10:16:35 2019 -0500

    Describe arbac02 checks
---
 README.md | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/README.md b/README.md
index 6162704..035a2dc 100644
--- a/README.md
+++ b/README.md
@@ -375,4 +375,77 @@ This enforcement mechanism maps roles to a given set of services.  The
following
 | Config  Manager   | true                     | false                    | false       
             | false                     | false                       | false           
            | false                        | false                    | false            
       | true                      |
 
 ___________________________________________________________________________________
+
+
+### Apache Fortress **ARBAC02 Checks**
+
+Disabled by default.  To enable, add this to fortress.properties file and restart instance:
+
+```concept
+# Boolean value. Disabled by default. If this is set to true, the runtime will enforce administrative
permissions and ARBAC02 DA checks:
+is.arbac02=true
+
+```
+
+These checks include the following:
+
+1. All API invocations calls checkAccess on an admin perm corresponding with the API being
called, e.g. AdminMgr.addUser.  This means at least one admin role activated for the caller
has to have been granted that particular permission.
+
+2. The assignUser, deassignUser, grantPermission, revokePermission APIs enforce administrative
authority over the role being targeted. This is being done by establishing a range of roles
(hierarchically), for which the target role falls inside.
+
+For example, the following top-down role hierarchy:
+
+       CTO
+        |
+    |       |
+   ENG      QC
+ |  |     |    |   
+E1  E2   Q1    Q2
+  |         |
+ DA         QA
+       |
+       A
+       
+Where a role called 'CTO' is the highest ascendant, and 'A' is the lowest descendant. In
a top-down role hierarchy, privilege increases as we descend in the tree.  So a person with
role 'A' inherits all that are above.
+
+In describing a range of roles, begin range is the lowest descendant in the chain, and end
range the highest. Furthermore a bracket, '[', ']', indicates inclusiveness, whereas parenthesis
indicates exclusiveness for a particular endpoint.
+
+Some example ranges that can be derived:
+
+a. [A, CTO] is the full set: {CTO, ENG, QC, E1, E2, Q1, Q2, DA, QA, A}.
+b. (A, CTO) is the full set, minus the endpoints: {ENG, QC, E1, E2, Q1, Q2, DA, QA}.
+c. [A, ENG] includes: {A, DA, E1, E2, ENG}
+d. [A, ENG) includes: {A, DA, E1, E2}
+etc...
+
+So, for an administrator to be able to target a role in one of the specified APIs above,
at least one of their activated admin roles must pass the role range test.  There are currently
two roles
+created by the security policy in this project, that are excluded from this type of check:
+fortress-rest-admin and fortress-core-super-admin
+
+Which means they won't have to pass the role range test.  All others use the range field
to define authority over a particular set of roles, in a hierarchical structure.
+                                         
+3. Some APIs on the AdminMgr do organization checks, matching the org on the admin role with
that on the target.  There are two types of organziations, User and Permission.
+
+For example, de/assignUser(User, Role) will verify that the caller has an admin role with
a matching user org unit (UserOU) on the target role.
+  
+There is similar check on grant/revokePermission(Role, Permission), where the caller must
have activated admin role matching the perm org unit (PermOU), corresponding with permission
being targeted.
+
+The complete list of APIs that enforce range and OU checks follow:
+
+| API                            | Validate UserOU  | Validate PermOU | Range Check On Role
|
+| ------------------------------ | ---------------- | -------------------------------------
|
+| AdminMgr.addUser               | true             | false           | false           
   |
+| AdminMgr.updateUser            | true             | false           | false           
   |
+| AdminMgr.deleteUser            | true             | false           | false           
   |
+| AdminMgr.disableUser           | true             | false           | false           
   |
+| AdminMgr.changePassword        | true             | false           | false           
   |
+| AdminMgr.resetPassword         | true             | false           | false           
   |
+| AdminMgr.lockUserAccount       | true             | false           | false           
   |
+| AdminMgr.unlockUserAccount     | true             | false           | false           
   |
+| AdminMgr.deletePasswordPolicy  | true             | false           | false           
   |
+| AdminMgr.assignUser            | true             | false           | true            
   |
+| AdminMgr.deassignUser          | true             | false           | true            
   |
+| AdminMgr.grantPermission       | false            | true            | true            
   |
+| AdminMgr.revokePermission      | false            | true            | true            
   |
+
 #### END OF README
\ No newline at end of file


Mime
View raw message