Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

The caller needs either fortress-rest-super-user or fortress-rest-admin-user RBAC role to invoke the specified service.

4. Apache Fortress ARBAC Checks

The Apache Fortress Administrative Role-Based Access Control (ARBAC) subsystem handles delegating administrative tasks to special users. Disabled in FortressRest by default, to enable, add the following declaration to the fortress.properties:

is.arbac02=true

a. When enabled, all service invocations perform an ADMIN permission verification by invoking DelAccessMgr.checkAccess down in the API layer.

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, and their mappings to services are listed in the table that follows.

b. Some services (#'s 1 - 12 in ARBAC table 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 organizations being checked, User and Permission.

For example, roleAsgn and roleDeasgn (9 and 10 in ARBAC table) 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 in ARBAC table) 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:

CTO
|
| |
ENG QC
| | | |
E1 E2 Q1 Q2
| |
DA QA
|
A1

Here a role called CTO is the highest ascendant in the graph, and A1 is the lowest descendant. In a top-down role hierarchy, privilege increases as we descend downward. So a person with role A1 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 with an endpoint, whereas parenthesis, ‘(’, ‘)’ will exclude a corresponding endpoint.

Some example ranges that can be derived from the sample role graph above:

For an administrator to be authorized to target an RBAC role in one of the specified APIs listed above, at least one of their activated ADMIN roles must pass the ARBAC 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.