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 master updated: cleanup
Date Sat, 16 Mar 2019 23:05:46 GMT
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/master by this push:
     new 57c6f09  cleanup
57c6f09 is described below

commit 57c6f09d1bb78eb25304c49b8dc59b5a7e6830ec
Author: Shawn McKinney <smckinney@apache.org>
AuthorDate: Sat Mar 16 18:05:41 2019 -0500

    cleanup
---
 README-SECURITY-MODEL.md | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/README-SECURITY-MODEL.md b/README-SECURITY-MODEL.md
index b98f043..0af4d6c 100644
--- a/README-SECURITY-MODEL.md
+++ b/README-SECURITY-MODEL.md
@@ -78,27 +78,27 @@ is.arbac02=true
 
 The ARBAC checks include the following:
 
-1. All service invocations map to DelAdminMgr.checkAccess calls using an ADMIN perm that
corresponding with the service/API being called, e.g. org.apache.directory.fortress.core.impl.AdminMgrImpl.addUser.
 
+1. All service invocations map to DelAccessMgr.checkAccess calls using an ADMIN perm that
corresponding with the service/API being called, e.g. *org.apache.directory.fortress.core.impl.AdminMgrImpl.addUser*.
 
  This means at least one ADMIN role activates that has been granted the required permission.
 
-2. The assignUser, deassignUser, grantPermission, revokePermission APIs enforce administrative
authority over the RBAC role being targeted. This is being done by establishing a range of
roles (hierarchically), for which the target role falls inside.
-
+2. The *assignUser*, *deassignUser*, *grantPermission*, *revokePermission* APIs enforce administrative
authority over the RBAC 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 contains an RBAC role hierarchy for a fictional software
development organization:
 
  ```
-        CTO
-         |
-     |       |
-    ENG      QC
-   |   |   |    |   
- E1   E2  Q1    Q2
-    |        |
-   DA        QA
+        *CTO*
+          |
+     |         |
+   *ENG*      *QC*
+   |   |     |    |   
+ *E1* *E2* *Q1*  *Q2*
+     |         |
+   *DA*       *QA*
          |
-         A
+        *A*
  ```
     
- Where a role called 'CTO' is the highest ascendant in the graph, and 'A' is the lowest descendant.
In a top-down role hierarchy, privilege increases as we descend downward.  So a person with
role 'A' inherits all that are above.
+ Where a role called *CTO* is the highest ascendant in the graph, and *A* is the lowest descendant.
In a top-down role hierarchy, privilege increases as we descend downward.  So a person with
role *A* inherits all that are above.
 
  In describing a range of roles, *beginRange* is the lowest descendant in the chain, and
*endRange* the highest. Furthermore a bracket, '[', ']', indicates inclusiveness, whereas
parenthesis indicates exclusiveness for a particular endpoint.
 
@@ -116,7 +116,7 @@ The ARBAC checks include the following:
 
  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.
+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.
   


Mime
View raw message