commit | 78002805919e3fd6dd741cff68fd9e649cdd4bf5 | [log] [tgz] |
---|---|---|
author | Shawn McKinney <smckinney@apache.org> | Sat Mar 16 10:25:22 2019 -0500 |
committer | Shawn McKinney <smckinney@apache.org> | Sat Mar 16 10:25:22 2019 -0500 |
tree | f4f17b83da2315e5006c037f93e9ffa220801e02 | |
parent | e970baf977b0975b9d5251e382853dbd3b4c51a5 [diff] |
Describe arbac02 checks
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.
This document contains instructions to download, build, and test operations using Apache Fortress Rest component.
Minimum hardware requirements:
Minimum software requirements:
Everything else covered in steps that follow. Tested on Debian, Centos systems.
a. from git:
git clone --branch 2.0.3 https://gitbox.apache.org/repos/asf/directory-fortress-enmasse.git cd directory-fortress-enmasse mvn clean install
b. or download package:
wget http://www.apache.org/dist/directory/fortress/dist/2.0.3/fortress-rest-2.0.3-source-release.zip unzip fortress-rest-2.0.3.zip cd fortress-rest-2.0.3 mvn clean install
mvn javadoc:javadoc
This web app uses Java EE security.
wget http://repo.maven.apache.org/maven2/org/apache/directory/fortress/fortress-realm-proxy/2.0.3/fortress-realm-proxy-2.0.3.jar -P $TOMCAT_HOME/lib
$TOMCAT_HOME
points to the execution env.Note: The realm proxy enables Tomcat container-managed security functions to call back to fortress.
sudo vi /usr/local/tomcat8/conf/tomcat-users.xml
<role rolename="manager-script"/> <user username="tcmanager" password="m@nager123" roles="manager-script"/>
cp src/main/resources/fortress.properties.example src/main/resources/fortress.properties
vi src/main/resources/fortress.properties
Pick either Apache Directory or OpenLDAP server:
a. Prepare fortress for ApacheDS usage:
# This param tells fortress what type of ldap server in use: ldap.server.type=apacheds # Use value from [Set Hostname Entry]: host=localhost # ApacheDS defaults to this: port=10389 # These credentials are used for read/write access to all nodes under suffix: admin.user=uid=admin,ou=system admin.pw=secret
-- Or --
b. Prepare fortress for OpenLDAP usage:
# This param tells fortress what type of ldap server in use: ldap.server.type=openldap # Use value from [Set Hostname Entry]: host=localhost # OpenLDAP defaults to this: port=389 # These credentials are used for read/write access to all nodes under suffix: admin.user=cn=Manager,dc=example,dc=com admin.pw=secret
mvn -version
This sample requires Java 8 and Maven 3 to be setup within the execution env.
mvn install -Dload.file=src/main/resources/FortressRestServerPolicy.xml
Build Notes:
-Dload.file
automatically loads the directory-fortress-rest security policy data into ldap.mvn
commands.a. If using autodeploy feature, verify the Tomcat auto-deploy options are set correctly in the pom.xml file:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.0-beta-1</version> <configuration> ... <url>http://localhost:8080/manager/text</url> <path>/${project.artifactId}</path> <username>tcmanager</username> <password>m@nager123</password> </configuration> </plugin>
b. Now, automatically deploy to tomcat server:
mvn clean tomcat:deploy
c. To automatically redeploy sample app:
mvn clean tomcat:redeploy
d. To manually deploy app to Tomcat:
cp target/fortress-rest-[version].war $TOMCAT_HOME/webapps
$TOMCAT_HOME
points to the execution env.Run unit test:
mvn test -Dtest=EmTest
Test Notes:
This section describes the properties needed to control fortress rest.
The host name can be specified as a fully qualified domain name or IP address:
# Host name and port of LDAP DIT: host=localhost port=10389
# If ApacheDS server: ldap.server.type=apacheds
# Else if OpenLDAP server: ldap.server.type=slapd
# Else leave blank: #ldap.server.type=other
This service account must have read/write privileges over the entire Fortress LDAP Directory Information Tree (DIT):
# If ApacheDS it will look something like this: admin.user=uid=admin,ou=system admin.pw=secret
# Else If OpenLDAP it will look something like this: admin.user=cn=Manager,dc=example,dc=com
# This is min/max settings for LDAP connections. For testing and low-volume instances this will work: min.admin.conn=1 max.admin.conn=10
Notes on connection pools:
This will match your LDAP‘s server’s config node per Fortress Core setup:
# This node contains fortress properties stored on behalf of connecting LDAP clients: config.realm=DEFAULT config.root=ou=Config,dc=example,dc=com
# Used for SSL Connection to LDAP Server: enable.ldap.ssl=true enable.ldap.ssl.debug=true trust.store=/fully/qualified/path/and/file/name/to/java/truststore trust.store.password=changeit trust.store.set.prop=true
# ApacheDS stores its password policies objects here by default: apacheds.pwpolicy.root=ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
Nothing special or unique going on here. Refer to the documentation of your servlet container for how to enable.
This enforcement mechanism maps roles to a given set of services. The following table shows what roles map to which (sets of) services:
service type | fortress-rest-super-user | fortress-rest-admin-user | fortress-rest-review-user | fortress-rest-access-user | fortress-rest-deladmin-user | fortress-rest-delreview-user | fortress-rest-delaccess-user | fortress-rest-pwmgr-user | fortress-rest-audit-user | fortress-rest-config-user |
---|---|---|---|---|---|---|---|---|---|---|
Admin Manager | true | true | false | false | false | false | false | false | false | false |
Review Manager | true | false | true | false | false | false | false | false | false | false |
Access Manager | true | false | false | true | false | false | false | false | false | false |
Delegated Admin | true | false | false | false | true | false | false | false | false | false |
Delegated Review | true | false | false | false | false | true | false | false | false | false |
Delegated Access | true | false | false | false | false | false | true | false | false | false |
Password Manager | true | false | false | false | false | false | false | true | false | false |
Audit Manager | true | false | false | false | false | false | false | false | true | false |
Config Manager | true | false | false | false | false | false | false | false | false | true |
Disabled by default. To enable, add this to fortress.properties file and restart instance:
# 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:
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.
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:
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.
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 |