Introducing a pythonic RBAC API

py-fortress is a Python API implementing Role-Based Access Control level 0 – Core.  It’s still pretty new so there’s going to be some rough edges that will need to be smoothed out in the coming weeks.

To try it out, clone its git repo and use one of the fortress docker images for OpenLDAP or Apache Directory.  The README has the details.

py-fortress git repo

The API is pretty simple to use.

Admin functions work like this

# Add User:
admin_mgr.add_user(User(uid='foo', password='secret'))

# Add Role:

# Assign User:
admin_mgr.assign(User(uid='foo'), Role(name='customer'))

# Add Permission:
admin_mgr.add_perm(Perm(obj_name='shopping-cart', op_name='checkout'))

# Grant:
admin_mgr.grant(Perm(obj_name='shopping-cart', op_name='checkout'),Role(name='customer')) 

Access control functions

# Create Session, False means mandatory password authentication.
session = access_mgr.create_session(User(uid='foo', password='secret'), False)

# Permission check, returns True if allowed:
result = access_mgr.check_access(session, Perm(obj_name='shopping-cart', op_name='checkout'))

# Get all the permissions allowed for user:
perms = access_mgr.session_perms(session)

# Check a role:
result = access_mgr.is_user_in_role(session, Role(name='customer'))

# Get all roles in the session:
roles = access_mgr.session_roles(session)


In addition, there’s the full compliment of review apis as prescribed by RBAC.  If interested, look at the RBAC modules:

Each of the modules have comments that describe the functions, along with their required and optional attributes.

Try it out and let me know what you think.  There will be a release in the near future that will include some additional tooling.  If it takes off, RBAC1 – RBAC3 will follow.


Frequently debated within info sec circles.  Which one of them is better?

Use the right tool for the job as they say. RBAC, like any access control model, has its weaknesses. Many are well understood, even discussed by the original NIST team who framed the model.

Comments on “A Critique of the ANSI Standard on Role-Based Access Control”

However, there are a number of common fallacies wrt how RBAC works.  For example…

1. RBAC is static. It cannot use contextual information e.g. time, user location, device type.

Constraints are commonly applied during user, role and permission activation in RBAC. For example, placing temporal constraints on a role activation. Indeed INCITS 494 prescribes their use:

5.4 RBAC Policy Enhanced Constraints

Enhanced constraints go beyond the INCITS 359 RBAC Standard by including additional types of constraints. Constraints on roles may be static or dynamic. Static constraints are applied off- line before the role is activated by the user. Dynamic constraints are applied on-line after the role(s) are activated. These enhanced dynamic constraints can introduce attributes into the RBAC environment.
INCITS 494-2012, p. 8

2. RBAC cannot perform dynamic segregation-of-duty.

RBAC supports dynamic SoD constraints. From the spec:

5.3.2 Dynamic Separation of Duty Relations

Dynamic Separation of Duty Relations Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions.
ANSI INCITS 359-2004, p. 10

3. It relies on custom code within application layers (API, apps, DB…) to implement finer-grained controls.

Presumably what is meant here is that custom code must be written because RBAC controls don’t adequately satisfy security requirements for authorization.

Where are ABAC’s published functional specifications? Where are the standard object (data) and functional (api) model for computing (and storing) its decisions?

Perhaps it is better to use a proven, non-standard ABAC implementation than a custom app widget? If that is what is being said then I agree, but neither are ideal.

ABAC has its place as does RBAC. Knowing when to use one, the other, or both, is important. Understanding the limitations and strengths of each is crucial before adequately addressing the challenges we face as security practitioners.

Apache Fortress Role Engineering Tutorial

Apache Fortress Role Engineering Tutorial

The goals of this tutorial are to

  • Gain understanding of the Role Based Access Control (RBAC) standard
  • Learn the repeatable steps of the Role Engineering Process
  • Learn about using the Apache Fortress RBAC engine

To get started, follow the instructions in the README located on github:

More info here: A Practical Guide to Role Engineering.

Apache Fortress SAML Demo

The aim of this tutorial is to connect Apache Directory Fortress with Spring Security SAML and a common Identity Provider – SSO It’s not intended to highlight all of the possible locations in code where security checks may be applied.  For that take a look at The Apache Fortress End-to-End Security Tutorial.

Fortress SAML Demo

Go to, complete the steps under the README.

More info here: Fortress-Saml-Demo


What Are Temporal Constraints?


Ability to control when an entity activation occurs based on time and date criteria.  Temporal constraints are typically applied during User and Role activation as part of an authentication or authorization check.

What Are They For?

Can be used to limit when a User may log onto or activate a particular Role within a security domain.  Follows the principle of least privilege as it ensures access rights are only granted when appropriate.

How Do They Work?

There may be policies to control what dates, times, and days of week a User may access a particular area of the system and in what Role.  Can also be used to enforce a lockout period when the User is inactive or otherwise away for an extended period of time.

Apache Fortress Temporal Constraints

Fortress allows constraints to be applied onto both User and Role entities.  There are rules that fire during an activation event (any policy enforcement API call):

  1. Can the entity be active on this Date?
  2. Is the entity within a lockout period?
  3. Has the entity exceeded a particular inactive period?
  4. Can the entity be used at this time?
  5. Can the entity be used on this day?
  6. Are there mutual exclusion constraints that prevent activating this entity?  (Roles Only)

These temporal constraint rules are pluggable and may be added, overridden or removed.

What is Delegated Administration?


The ability to control access on the security system itself.  This control is exercised inside the policy administration programs.

In addition to what functions may be executed, we must control which entities to operate on.  A common use case is to allow User X the ability to reset and unlock passwords only for Users within Organization Y.  Another is the administrator may only assign a specific subset of Roles to Users who reside inside their Organization.  Additionally we must also be able to limit an Administrator to a specific subset of Roles in which to Grant to a subset of Permissions.  Indeed every API that changes state inside the back-end security repository must be governed via a well understood delegated administration policy.

Administrative Role-Based Access Control (ARBAC)

Apache Fortress has implemented ARBAC02. [link to paper].  This is a formal model for Delegated Administration and builds on the ANSI RBAC specification.  The control is marshaled into three interfaces:

  1. Delegated Admin Manager – Provides CRUD for related entities like Administrative Roles and Permissions.
  2. Delegated Review Manager – Interrogation of Delegated Admin policy objects.
  3. Delegated Access Manager – Enforcement of Delegated Administration Policies.

1 & 2 are for management of the Delegated Admin policies themselves.  3 is for enforcement of Delegated Admin policies at runtime.

Delegated Admin Policy Enforcement

There are two types of controls:

  1. Ensure that the caller has the permission to call the security administrative method (e.g. addUser, addRole, addPermission,…)
  2. Ensure the caller is entitled to perform the function for a given organization (e.g. which Users and Permissions to grant access rights).

With Fortress, the Delegated Administration control is baked into its APIs.  The enforcement occurs during API invocation which means it can’t be circumvented by poorly implemented administrative programs.

In addition to control, every API invocation leaves an audit trail so you may determine what policies changed, by whom, when and where.

Enabling Java EE and Fortress Security inside an Apache Wicket Web App

JavaDukeJammingfortress100    Wicket-Image


The aim of this tutorial is to demonstrate how a simple wicket web app can be converted to use java EE and fortress security.  It’s not intended to highlight all of the possible locations in code where security checks may be applied.  For that take a look at The Apache Fortress End-to-End Security Tutorial.

Course Prerequisites

Before starting, you need a working fortress environment up and running.  Complete one of the following:

 Steps to Enable Security in Wicket Sample

1. Download the fortress wicket-sample project

a. extract the zip

b. follow the instructions in

You may now hit the sample web app:


no security

no security

This is the view you will see when clicking on link for Page1.  Despite what it says about rbac perms, it’s an example of an app that’s not secured.  Users are not required to logon and may navigate freely.

To enable security for this app, continue on…

The following instructions are duplicated by:

2. Add the Java EE security required artifacts

If you are using the wicket-sample source, this is already done.  It includes wicket components, (plus associated markup files LoginPage.html, LogoutPage.html), and the static html files under the /login folder.  These files control the flow between the container and wicket with java EE security enabled.

java EE login page

java EE login page

more on java EE security

Declarative style of security, one with no api calls made by programmer (during logon).  This makes java EE security both error resistant and hardened to attack, though it tends to get in the way of the page flows.  We’ll cover this topic, in more detail, on a future post.

3. Edit the pom.xml

Prepare maven for fortress.

a. Uncomment the fortress web dependency at the top of the file.

 <!-- TODO STEP 3: uncomment for fortress security dependency: -->

b. Uncomment the maven ant task near the bottom of the file.

This plugin calls the fortress load procedure during normal maven tasks like install or deploy.  The fortress load inserts the app’s security policy into ldap.  It can be overridden by passing param -Dnoload which tells the plugin not to execute.

     <target name="fortress-load"
       description="Loads wicket sample security policy into ldap">

At the completion of this step, the necessary binaries will be available to the app and the app’s security policy file will be ready to load.

4. Edit the web.xml

Prepare the app for fortress.

a. Uncomment the spring settings.

 <!-- TODO STEP 4a: uncomment to enable fortress spring bean injection: -->


Notice that we’re including a link to a spring context file: applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
  <bean id="accessMgr" 
    <constructor-arg value="HOME"/>

  <bean id="j2eePolicyMgr" 

The context file holds the metadata necessary to wire the fortress objects in with their constructors and subsequently get injected into the web app as spring beans.

b. Uncomment the java ee security constraints from web.xml:

 <!-- TODO STEP 4b: uncomment to enable Java EE Security: -->

Now container security has been enabled for this web app.  It authenticates, checks roles and maintains the session.

The wicket logout page is excluded from java EE security constraints.  Otherwise, a problem occurs preventing unauthorized users from logging out.

   <!-- OMIT auth-constraint -->

5. Rename context.xml.example to context.xml

Prepare the app for the fortress realm.

<Context reloadable="true">
 <Realm className=""

This file hooks a web app into the tomcat fortress realm which performs security functions like authenticate and isUserInRole. It’s also where the security session gets created by fortress.

more on the realm

The fortress realm’s proxy jar must be present under tomcat’s lib folder (as discussed in the quickstarts).

The proxy jar is a shim that uses a URLClassLoader to reach its implementation libs.  The proxy prevents the realm impl libs, pulled in as dependency to web app, from interfering with the container’s system classpath thus providing an error free deployment process free from classloader issues.  The proxy offers the flexibility for each web app to determine its own version/type of security realm to use, satisfying a variety of requirements related to web hosting and multitenancy.

6. Rename to

Prepare fortress for either apacheds or openldap server usage.

Pick One:

a. ApacheDS

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

# ldap host:

# ldap port:

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

# This is min/max settings for LDAP administrator pool connections that have read/write access to all nodes under suffix:

# This node contains fortress properties stored on behalf of connecting LDAP clients:

# Used by application security components:

# Fortress uses a cache:

b. OpenLDAP

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

# ldap host:

# openldap default port:

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

# This is min/max settings for LDAP administrator pool connections that have read/write access to all nodes under suffix:

# This node contains fortress properties stored on behalf of connecting LDAP clients:

# Used by application security components:

# Fortress uses a cache:

7. Edit

Tell wicket about fortress sessions and objects.

a. Uncomment fortress session override.

Here we override app’s wicket session with a new one that can hold onto fortress session and perms:

 // TODO STEP 7a: uncomment save fortress session to wicket session:
 public Session newSession(Request request, Response response)
   return new WicketSession(request);

b. Uncomment fortress spring bean injector.

Next we tell the app to use spring to inject references to fortress security objects:

 // TODO STEP 7b: uncomment to enable injection of fortress spring beans:
 getComponentInstantiationListeners().add(new SpringComponentInjector(this));

These steps are necessary to get fortress runtime wired into the sample app.

8. Edit

Get fortress objects injected to the wicket base page, enable fortress secured page links.

a. Uncomment fortress spring bean injection.

This step automatically instantiates the fortress objects needed for security processing.

 // TODO STEP 8a: enable spring injection of fortress bean here:
 private AccessMgr accessMgr;

 private J2eePolicyMgr j2eePolicyMgr;

These objects are used by the app to make AccessMgr calls to functions like checkAccess and sessionPermissions.

b. Uncomment call to enableFortress.

This performs the boilerplate security functions required by fortress during app session startup:

 // TODO STEP 8b: uncomment call to enableFortress:
      this, ( HttpServletRequest ) getRequest().getContainerRequest(), 
      j2eePolicyMgr, accessMgr );
 catch ( se)

c. Change to FtBookmarkablePageLink

The advantage here is other than a name change, everything else stays the same, and now the links are secured.

 // TODO STEP 8c: change to FtBookmarkablePageLink:
 add( new FtBookmarkablePageLink( "", Page1.class ) );
 add( new FtBookmarkablePageLink( "", Page2.class ) );
 add( new FtBookmarkablePageLink( "", Page3.class ) );

This component maps a page link to a fortress permission.  The wicket id passed in, e.g., is converted to a fortress permission, objName: page1, opName: link.

9. Edit,,

Enable fortress secured buttons.  Each page has three buttons.  Same as before, only the name changes.

a – i. change the button class name to FtIndicatingAjaxButton:

 // TODO STEP 9a: change to FtIndicatingAjaxButton:
 add( new FtIndicatingAjaxButton( "page1.button1" )

This component maps the buttons to fortress permissions.  The wicket id, e.g. page1.button1, is converted to a fortress permission, objName: page1, opName: button1.

10. Build & Deploy Web App

Deploy to tomcat server:

mvn clean tomcat:deploy -Dload.file

Or if already deployed:

mvn clean tomcat:redeploy -Dload.file

The -Dload.file system parameter tells maven to load the wicket sample security policy into ldap in addition to deploying the app.  Since the load needs to happen just once, you may drop it from future invocations:

mvn tomcat:redeploy

We’re done with setup.  Now onto testing…

Testing the Sample App Security Policy

The wicket-sample security policy is loaded automatically during maven deployment step.  The file:  wicket-sample-security-policy.xml

How to create an rbac policy was covered recently:

The Seven Steps of Role Engineering

The diagram below depicts the wicket sample role hierarchy and its user to role assignments:

sample security policy

sample security policy

  • wsBaseRole is inherited by all other roles
  • wsSuperUsers inherits wsUsers1Role, wsUsers2Role and wsUsers3Role
  • wsUser1 is assigned wsUsers1Role and has access to buttons on Page1
  • wsUser2 is assigned wsUsers2Role and can hit buttons on Page2
  • wsUser3 is assigned wsUsers3Role and has buttons on Page3
  • wsSuperUser is assigned wsSuperUser role has all pages and all buttons

Use Cases for Testing

a. wssuperuser/password

Receives links for Page1, Page2 and Page3.

wsSuperUser launch page

wsSuperUser launch page

b. wsuser1/password

Receives a page link for Page1.  May only view and click on Page1’s buttons.

wsUser1 launch page

wsUser1 launch page

c. wsuser2/password

Receives link for Page2.  May only view and click on Page2’s buttons.

wsUser2 launch page

wsUser2 launch page

d. wsuser3/password

Receives link for Page3.  May only view and click on Page3’s buttons.

wsUser3 launch page

wsUser3 launch page

More on sample security policy

As stated in the beginning, the sample wicket security controls are not comprehensive.  For example, a user may navigate by manually entering page urls thus sidestepping the secured page link component.  In this scenario the user will be prevented from clicking on buttons unless otherwise authorized.  Still, allowing users to navigate to unauthorized pages is a bad practice.  The Apache Fortress End-to-End Security Tutorial uses spring security controls to lock down pages.  There are many other ways – how would you do it?