Skip to content
Go to file
Cannot retrieve contributors at this time
348 lines (240 sloc) 12.1 KB

Overview of the rbac-abac-sample README

Table of Contents

  • SECTION 1. Prerequisites
  • SECTION 2. Prepare Tomcat for Java EE Security
  • SECTION 3. Prepare rbac-abac-sample package
  • SECTION 4. Build and deploy rbac-abac-sample
  • SECTION 5. Understand the security policy
  • SECTION 6. Manually Test the RBAC with ABAC sample
  • SECTION 7. Automatically Test the RBAC with ABAC sample (using Selenium)
  • SECTION 8. Under the Hood (Learn how it works here)

SECTION I. Prerequisites

  1. Java 8
  2. Apache Maven 3++
  3. Apache Tomcat 8++
  4. Basic LDAP server setup by completing one of these:

SECTION II. Prepare Tomcat for Java EE Security

This sample web app uses Java EE security.

1. Download the fortress realm proxy jar into tomcat/lib folder:

wget -P $TOMCAT_HOME/lib
  • Where $TOMCAT_HOME points to the execution env.

Note: The realm proxy enables Tomcat container-managed security functions to call back to fortress.

2. Optional - Prepare tomcat to allow autodeploy of rbac-abac-sample web app:

sudo vi /usr/local/tomcat8/conf/tomcat-users.xml

3. Optional - Add tomcat user to deploy rbac-abac-sample:

<role rolename="manager-script"/>
<user username="tcmanager" password="m@nager123" roles="manager-script"/>

4. Restart tomcat for new settings to take effect.

SECTION III. Prepare rbac-abac-sample package

1. Stage the project.

a. Download and extract from Github:


-- Or --

b. Or git clone locally:

git clone

2. Change directory into it:

cd rbac-abac-sample

3. Enable an LDAP server:

a. Copy the example:

cp src/main/resources/ src/main/resources/

b. Edit the file:

vi src/main/resources/

Pick either Apache Directory or OpenLDAP server:

c. Prepare fortress for ApacheDS usage:

# This param tells fortress what type of ldap server in use:

# Use value from [Set Hostname Entry]:

# ApacheDS defaults to this:

# These credentials are used for read/write access to all nodes under suffix:

-- Or --

d. Prepare fortress for OpenLDAP usage:

# This param tells fortress what type of ldap server in use:

# Use value from [Set Hostname Entry]:

# OpenLDAP defaults to this:

# These credentials are used for read/write access to all nodes under suffix:

SECTION IV. Build and deploy rbac-abac-sample

1. Verify the java and maven home env variables are set.

mvn -version

This sample requires Java 8 and Maven 3 to be setup within the execution env.

2. Build the sample and load test data:

mvn install -Dload.file

Build Notes:

  • -Dload.file automatically loads the rbac-abac-sample security policy data into ldap.
  • This load needs to happen just once for the default test cases to work and may be dropped from future mvn commands.

3. Deploy the sample to Tomcat:

a. If using autodeploy feature, verify the Tomcat auto-deploy options are set correctly in the pom.xml file:


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/rbac-abac-sample.war $TOMCAT_HOME/webapps
  • Where $TOMCAT_HOME points to the execution env.

SECTION V. Understand the security policy

To gain full understanding, check out the file used to load it into the LDAP directory: rbac-abac-sample security policy.

App comprised of three pages, each has buttons and links that are guarded by permissions. The permissions are granted to a particular user via their role activations.

1. User-to-Role Assignment Table

For this app, user-to-role assignments are:

user Tellers Washers
curly true true
moe true true
larry true true

2. User-to-Role Activation Table by Branch

But we want to control role activation using attributes based on Branch location:

user Tellers Washers
curly East North, South
moe North East, South
larry South North, East

Even though the test users are assigned both roles, they are limited which can be activated by branch.

3. Role-to-Role Dynamic Separation of Duty Constraint Table

Furthermore due to toxic combination, we must never let a user activate both roles simultaneously regardless of location. For that, we'll use a dynamic separation of duty policy.

set name Set Members Cardinality
Bank Safe Washers 2

4. Role-Permission Table Links

The page links are guarded by RBAC permissions that dependent on which roles are active in the session.

role WashersPage TellersPage
Tellers false true
Washers true false

5. Role-Permission Table Buttons

The buttons on the page are also guarded by RBAC permissions.

role Account.deposit Account.withdrawal Account.inquiry Currency.soak Currency.rise Currency.dry
Tellers true true true false false false
Washers false false false true true true

SECTION VI. Manually Test the RBAC with ABAC sample

1. Open link to http://localhost:8080/rbac-abac-sample

2. Login with Java EE authentication form:

3. User-Password Table

userId Password
curly password
moe password
larry password

4. Enter a location for user and click on the button.

Enter North, South or East


5. Once the location is set, a link will appear corresponding with the user's allowed role for that location.


6. Click on the link, and then buttons appear simulating user access for that particular location.


7. Change locations, and a different link appears, with different operations.

This is RBAC with ABAC in action, limiting which role may be activated in the session by location.

8. Try a different user.

Each has different access rights to application.

SECTION VII. Automatically Test the RBAC with ABAC sample

Run the selenium automated test:

mvn test -Dtest=RbacAbacSampleSeleniumITCase

Selenium Test Notes:

  • This test will log in as each user, perform positive and negative test cases.
  • Requires Firefox on target machine.

SECTION VII. Under the Hood

How does this work? Have a look at some code...

Paraphrased from

// Nothing new here:
 User user = new User(userId);

 // This is new:
 RoleConstraint constraint = new RoleConstraint( );

 // In practice we're not gonna pass hard-coded key-values in here, but you get the idea:
 constraint.setKey( "locale" );
 constraint.setValue( "north" );

 // This is just boilerplate goop:
 List<RoleConstraint> constraints = new ArrayList();
 constraints.add( constraint );

     // Now, create the RBAC session with an ABAC constraint, locale=north, asserted:
     Session session = accessMgr.createSession( user, constraints );

Pushing the locale attribute into the User's RBAC session the runtime will match that instance data with their stored policy.

Image4 Notice that this user has been assigned both Teller and Washer, via ftRA attribute, and that another attribute, ftRC, constrains where it can be activated.

How the ABAC algorithm works:

  • When the runtime iterates over assigned roles (ftRA), trying to activate them one-by-one, it matches the constraint pushed in, e.g. locale=north, with its associated role constraint (ftRC).
  • If it finds a match, the role can be activated into the session, otherwise not.

When does it get executed:

One more thing:

  • ABAC constraints work with any kind of instance data, e.g. account, organization, etc. Let your imagination set the boundaries.
You can’t perform that action at this time.