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: more cleanup
Date Sat, 16 Mar 2019 23:53:27 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 aca68f2  more cleanup
aca68f2 is described below

commit aca68f22a4bc351dbba34a666abfb925f144ed24
Author: Shawn McKinney <smckinney@apache.org>
AuthorDate: Sat Mar 16 18:53:22 2019 -0500

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

diff --git a/README-SECURITY-MODEL.md b/README-SECURITY-MODEL.md
index 5e662d2..0f59184 100644
--- a/README-SECURITY-MODEL.md
+++ b/README-SECURITY-MODEL.md
@@ -24,6 +24,7 @@ ________________________________________________________________________________
  * 1. Java EE security
  * 2. Apache CXF's **SimpleAuthorizingInterceptor**
  * 3. Apache Fortress **ARBAC02 Checks**
+ * The list of APIs that enforce ARBAC role range and OU checks.
 ___________________________________________________________________________________
 
 ## Document Overview
@@ -76,15 +77,18 @@ is.arbac02=true
 
  ```
 
-The ARBAC checks include the following:
+The ARBAC checks when enabled, include the following:
 
-1. All service invocations map to DelAccessMgr.checkAccess calls using an ADMIN perm that
corresponding with the service/API being called, e.g. objectName **org.apache.directory.fortress.core.impl.AdminMgrImpl**,
operation name: **addUser**.
- This ADMIN perm will be executed automatically during the call to the **userAdd** service
(if ARBAC checking is enabled)  
- This means at least one ADMIN role activates that has been granted the required permission.
+1. All service invocations perform an ADMIN permission check automatically corresponding
with the exact service/API being called. 
+ 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 can be found here: [FortressRestServerPolicy](./src/main/resources/FortressRestServerPolicy.xml)
along with a sample policy that can be used for testing.
 
-2. The Apache Fortress REST **roleAsgn**, **roleDeasgn**, **roleGrant** and **roleRevoke**
services map to the **assignUser**, **deassignUser**, **grantPermission**, **revokePermission**
Apache Fortress Core AdminMgr APIs respectively.
- During service dispatch to the APIs, the runtime will enforce ADMIN authority over the particular
RBAC role that is being targeted in the HTTP request. 
- These checks are based on a range of roles (hierarchically), for which the target role must
fall inside.   
+2. Some services (listed below) perform an ARBAC role range check on the target RBAC role.

+ The Apache Fortress REST **roleAsgn**, **roleDeasgn**, **roleGrant** and **roleRevoke**
services map to the **assignUser**, **deassignUser**, **grantPermission**, **revokePermission**
Apache Fortress Core AdminMgr APIs respectively.
+ During service dispatch of these APIs, the runtime 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:
 
  ```
@@ -119,13 +123,11 @@ 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 (listed below) do organization checks, matching 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, de/assignUser(User,
Role) 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 grant/revokePermission(Role, Permission), verifying the caller
has an activated ADMIN role with a perm org unit that matches the ou on the target permission.
 
- For example, de/assignUser(User, Role) will verify that the caller has an ADMIN role with
a user org unit that matches the ou of the target user.
-  
- There is similar check on grant/revokePermission(Role, Permission), where the caller must
have activated ADMIN role with a perm org unit that matches the ou on the target permission.
-
- The complete list of APIs that enforce range and OU checks follow:
+### The list of APIs that enforce ARBAC role range and OU checks.
 
 | API                            | Validate UserOU  | Validate PermOU | Range Check On Role
| 
 | ------------------------------ | ---------------- | ----------------| -------------------
| 


Mime
View raw message