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.

Secure Web Apps with JavaEE and Apache Fortress

ApacheCon is just a couple months away — coming up May 16-18 in Miami. We asked Shawn McKinney, Software Architect at Symas Corporation,  to share some details about his talk at ApacheCon. His presentation — “The Anatomy of a Secure Web Application Using Java EE, Spring Security, and Apache Fortress” will focus on an end-to-end application security architecture for an Apache Wicket Web app running in Tomcat. McKinney explains more in this interview.

Source: Secure Web Apps with JavaEE and Apache Fortress

Project Link: Apache Fortress Demo Project

On the Essential Question of Identity

For years I’ve been on record proclaiming that identity centralization is good and synchronization is bad.  I reasoned it is better to re-engineer processes to share identities than to distribute and fragment them.

I still believe this to be true.  However I have come to realize that centralization of identities will not happen — during our lifetimes.  The reasons are numerous, obvious, and beyond the scope of this post.

Where does this leave us on the essential question, i.e. how do we maintain identities now they must be distributed across the known universe?

The answer to this question will included within a series of blog posts.  Stay tuned…


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.

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.