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: refine
Date Sun, 17 Mar 2019 15:49:13 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 4c62d38  refine
4c62d38 is described below

commit 4c62d38db2d262eb37cf88a16c0724e581ab1649
Author: Shawn McKinney <smckinney@apache.org>
AuthorDate: Sun Mar 17 10:49:08 2019 -0500

    refine
---
 README-SECURITY-MODEL.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/README-SECURITY-MODEL.md b/README-SECURITY-MODEL.md
index a09286e..a5a1b44 100644
--- a/README-SECURITY-MODEL.md
+++ b/README-SECURITY-MODEL.md
@@ -87,15 +87,16 @@ a. All service invocations, except AccessMgr and DelAccessMgr, perform
an ADMIN
  For example, the permission with an objectName: **org.apache.directory.fortress.core.impl.AdminMgrImpl**
and operation name: **addUser** is automatically checked
  during the call to the **userAdd** service.   
  This means at least one ADMIN role must be activated for the user calling the service that
has been granted the required permission.
- The entire list of permissions in the table below..
+ The entire list of permissions, and their mappings to services are listed in the table that
follows.
 
-b. Some services (#'s 1 - 12 listed below) do organization checks, comparing the org on the
ADMIN role with that on the target user or permission.  
- There are two types of organziations, User and Permission.  For example, **roleAsgn** and
**roleDeasgn**  (9 and 10 below) will verify that the caller has an ADMIN role with a user
org unit that matches the ou of the target user.  
+b. Some services (#'s 1 - 12 listed below) perform organizational verification, comparing
the org on the ADMIN role with that on the target user or permission in the HTTP request.
 
+ There are two types of organziations being checked, User and Permission.  For example, **roleAsgn**
and **roleDeasgn**  (9 and 10 below) will verify that the caller has an ADMIN role with a
user org unit that matches the ou of the target user.  
  There is a similar check on **roleGrant** and **roleRevoke** (11 and 12) verifying the caller
has an activated ADMIN role with a perm org unit that matches the ou on the target permission.
 
-c.. Some services (#'s 9,10,11,12) perform an ARBAC role range check on the target RBAC role.

+c. Some services (#'s 9,10,11,12) perform a range check on the target RBAC role to verify
user has matching ADMIN role with authority to assign to user or grant to permission. 
  The Apache Fortress REST **roleAsgn**, **roleDeasgn**, **roleGrant** and **roleRevoke**
services will enforce ADMIN authority over the particular RBAC role that is being targeted
in the HTTP request. 
  These checks are based on a (hierarchical) range of roles, for which the target role must
fall inside.   
+ 
  For example, the following top-down contains a sample RBAC role hierarchy for a fictional
software development organization:
 
  ```


Mime
View raw message