by Shawn McKinney

Towards an Attribute-Based Role-Based Access Control System

[Link to the Apache Fortress RBAC-ABAC-SAMPLE project on Github]

[Link to towards-an-attribute-based-rbac-ldapcon-2019-v1 from LDAPCon]

We’ve all heard the complaint, RBAC doesn’t work.  It leads to Role Explosion, defined as an inordinate number of roles in a production environment.  Nobody knows who must be assigned to what because there are hundreds if not thousands of them.

What’s a system implementor to do?  We could give Attribute-Based Access Control a try, but that has its own problems and we need not go there again.

There’s another way.  RBAC allows the usage of dynamic attributes.

  • Recent standards include dynamic policies, most notably, ANSI INCITS 494 RBAC Policy-Enhanced
  • The existence of entities to conveniently apply dynamic policies, e.g. User-Role and Role-Permission.
  • No language discouraging the usage of dynamic attributes alongside RBAC in the standard.

Indeed, dynamic attributes are encouraged if not prescribed.  Here’s where I should be pointing to evidence substantiating my arguments.

http://lmgtfy.com/?q=NIST+and+ANSI+and+RBAC+and+attributes

This brings us to Apache Fortress and a new enhancement to use dynamic attributes.

What is Apache Fortress?

Both followers of this blog (wife and boss) know about Apache Fortress.  Especially my wife.  It’s the itch that leads me to three years of work in a garage, alongside two of my brothers, who got dragged in also.

It’s also an implementation of the classic RBAC specification – ANSI INCITS 359.  If anything’s prone to exploding roles, it’s Apache Fortress.

How are we going to stop the dang exploding?

Described in a JIRA ticket  yesterday, and checked into the Apache Fortress Core Repo last night.  The idea is best explained with a story.

The Tale of Three Stooges and Three Branches

Once upon a time there were three branches, North, South and East managed by The Three Stooges that worked there, Curly, Moe and Larry.

They were nice blokes, but a tad unruly, and so we try to keep them separated.  Curly works in the East, Moe the North and Larry runs amok in the South.  All three are Tellers, but each may also substitute as coin Washers at the other two.

All is well because each Branch has only one Teller.  It’s never good when two Stooges combine without one being in charge.

Here are the Users and their Role assignments:

Curly: Teller, Washer

Moe: Teller, Washer

Larry: Teller, Washer

By now we know where this storyline’s headed.  How do we prevent one going off-script, wandering into another branch, activating Teller, and running slipshod?

The classic Role explosion theory goes like…

Create Roles by Location with User-Role assignments:

Curly: TellerEast, WasherNorth, WasherSouth

Moe: TellerNorth, WasherEast, WasherSouth

Larry: TellerSouth, WasherNorth, WasherEast

This works pretty good with three branches and two roles but what about the real-world?  How many branches will the medium-sized bank have, a thousand?  How many types of roles, at least ten?  If we follow the same Role-by-Location pattern there’d be over 10,000 Roles to manage!  We may be keeping our Stooges in check, but at the IT team’s expense.  Our roles have indeed exploded.  What now?

Time for something different, back to the earlier discussion over using attributes.  Let’s try controlling role activation by location, but store the required attributes on the user object itself.

User-Properties to store Role-Locale constraints:

Curly: Teller:East, Washer:North, Washer:South

Moe: Teller:North, Washer:East, Washer:South

Larry: Teller:South, Washer:North, Washer:East

What just happened here?  It kind of looks the same but it’s not.  We go back to only needing two Roles, but have added dynamic policies, Role-Locale, to properties stored on the User.  Our medium-sized bank only needs 10 roles not 10,000.

Now, when the security system logs in a User (createSession), it pushes its physical location attribute into the runtime context, e.g. North, South or East, along with the already present Userid attribute.  The security system compares that physical location, along with its corresponding properties stored on the User, to determine access rights, specifically which Roles may be activated into their Session.

Sprinkle in a policy that defines the role to constraint relationships.

Global Config Properties store Role-Constraint mappings:

Teller:Locale

Washer:Locale

That way when the security system activates roles it knows to perform the extra check on a particular role, and which attribute to verify.

In addition to location, we can constrain role activation by project, organization, customer, account balance, hair color, favorite ice cream, and any other form of instance data imaginable.  There may be multiple types of constraints applied to any or all roles in the system.  It truly is a dynamic policy mechanism placed on top of a traditional Role-Based Access Control System.

With this minor change to the security system, our IT guys return to the good life without worrying about exploding roles or what the Stooges are up to.  🙂

The End

 

 

by Shawn McKinney

DirtyKanza Training on Zwift?

Due to an injury on March 14th, discussed here, the last couple months of my Dirty Kanza training was done on a smart trainer, using the Zwift virtual training app.

IMG_20180422_091742_846

My Setup includes a CycleOps Magnus Smart Trainer

The Dirty Kanza is an ultra-endurance cycling event held every year over the Flint Hills of Kansas.

20180602_203806

Sundown was around mile one fifty during this year’s Kanza ride

The plan was pretty simple.  Focus on time and power rather than distance or speed.  The goal, twelve hours in the saddle, at whatever wattage could be mustered, 75% of the expected duration to complete the 206 mile course, in a single day.  Every week go a bit longer on the long day.  Work up to the peak, May 13th.  Afterwards, taper down, sprinkle in some real rides on pavement and gravel and prepare for the event on June 2nd.

Here’s the training plan in Strava (hours):

Screen Shot 2018-06-08 at 3.29.59 PM

Screenshot of Training Plan in Strava (hours)

How’d it go?  Still in the Breakfast Club (back of the pack) but shaved a bit off last year’s time.  It was another tough year, featuring stiff headwinds during the last half of the ride.  Out of 1,016 starters, 746 finished.

The official time:

Screen Shot 2018-06-09 at 9.38.36 AM

Screenshot of Results on Chronotrack

The ride on Strava:

Screen Shot 2018-06-08 at 3.36.05 PM

Screenshot of Ride on Strava

by Shawn McKinney

New Sheriff in Town

And it don’t need no stinking badges.  Yeah, I’m mixing clichés, happens sometimes when coding long hours in a stretch.  🙂

What I’m talking about is a new access management system, released to PyPI yesterday for the first time.

py-fortress on PyPI

Considering we just started coding a couple of months ago that’s pretty good progress.

What is it?  A toolkit designed for Python3, with APIs that developers can use to do security in an RBAC-compliant way.  Today, it requires an LDAP server to store the policies, but a file-based backend will soon be ready.  No, I’m not recommending files in production, but it’s fine for getting started, within dev envs.

You can check the py-fortress project here:

py-fortress README on GitHub

Inside are links to some documents to help get started.  The quickstart doesn’t require cloning the project GIT repo, but you’ll need a Linux machine, Python3, PIP and Docker engine installed.  Everything else is covered.

Why would you want it?  That’s a long story.  It starts with an imperative to follow standards, in security processes, like authentication and authorization.  That there’s value in committing to best-practices, in this case ANSI RBAC.

It may help to know that this effort is backed by my employer — Symas.

Eventually, this code may end up inside of an Apache project, like Apache Fortress.  Or, it might land somewhere else.  It’s too early to know.  What’s certain is that it’ll remain open, available to use and learn from.

by Shawn McKinney

Programming in Python using the py-fortress RBAC APIs

py-fortress implements standards-based RBAC in Python. There have been numerous postings lately here about it.

Prerequisites

Very soon we’ll have a release of py-fortress that works with just the file system. This is to lower complexity of testing and developing with this package. In the meantime, an LDAP server has to be running on the network, so follow the instructions in the quickstart below to use a Docker container, if you don’t already have one installed.

0. Prepare your python module for usage by importing:
from pyfortress import (
    # model
    User,
    Role,
    Perm,
    PermObj,
    # apis:
    review_mgr, 
    admin_mgr, 
    access_mgr,
    #exception handling:
    FortressError,
    global_ids
)

Access Mgr APIs – Create Session, Check Access, Session Perms

These are used to check the policies at runtime. For example, to authenticate is create_session and authorization is check_access here.

  1. Now test signing on the RBAC way: 
    def test_create_session(self):
    """
    create session
    """
    print('test_create_session')
    
    try:
        session = access_mgr.create_session(User(uid='foo1', password='secret'), False)
        if not session:
            print('test_create_session fail')
            self.fail('test_create_session fail')
        else:
            print('test_create_session pass')
            pass                        
    except FortressError as e:
        self.fail('test_create_session failed, exception=' + e.msg)

    The session will then be held on to by the client for subsequent calls like check_access and session_perms

  2. Here’s how to check a single permission: 
    def test_check_access(self):
    """
    create session and check perm
    """
    print('test_check_access')
    
    try:
        session = ... obtained earlier
        result = access_mgr.check_access(session, Perm(obj_name='ShoppingCart', op_name='add'))
        if not result:
            print('test_check_access fail')
            self.fail('test_check_access fail')
        else:
            print('test_check_access pass')
            pass                        
    except FortressError as e:
        self.fail('test_check_access failed, exception=' + e.msg)
  3. Retrieve all of the permissions as a list: 
    def test_session_perms(self):
    """
    create session and get perms for user
    """
    print('test_check_access')
    
    try:
        session = ... obtained earlier
        perms = access_mgr.session_perms(session)
        if not perms:
            print('test_session_perms failed')
            self.fail('test_session_perms failed')
        
        for perm in perms:
            print_perm(perm, 'session_perms: ')
        pass                        
    except FortressError as e:
        self.fail('test_session_perms failed, exception=' + e.msg)

Admin and Review APIs – Create, Read, Update, Delete

These are for programs that manage and search the data. For example admin guis, conversion programs, reporting apps.

  1. Add a user: 
    def test_add_user(self):
    """
    Add a basic user
    """
    print('test_add_user')
    
    try:
        admin_mgr.add_user(User(uid='foo1', password='secret'))
        print('test_add_user success')                        
    except FortressError as e:
        self.fail('test_add_user failed, exception=' + e.msg)
  2. Add a role: 
    def test_add_role(self):
    """
    Add a basic role
    """
    print('test_add_role')        
    try:
        admin_mgr.add_role(Role(name='Customer'))
        print('test_add_role success')                        
    except FortressError as e:
        self.fail('test_add_role failed, exception=' + e.msg)
  3. Add an object: 
    def test_add_obj(self):
    """
    Add a basic perm object
    """
    print('test_add_obj')
    
    try:
        admin_mgr.add_object(PermObj(obj_name='ShoppingCart'))
        print('test_add_obj success')                        
    except FortressError as e:
        self.fail('test_add_obj failed, exception=' + e.msg)
  4. Add a perm: 
    def test_add_perm(self):
    """
    Add a basic perm
    """
    print('test_add_perm')
    
    try:
        admin_mgr.add_perm(Perm(obj_name='ShoppingCart', op_name='add'))
        print('test_add_perm success')                        
    except FortressError as e:
        self.fail('test_add_perm failed, exception=' + e.msg)
  5. Assign a user: 
    def test_assign_user(self):
    """
    Assign a user to a role
    """
    print('test_assign_user')
    
    try:
        admin_mgr.assign(User(uid='foo1'), Role(name='Customer'))
        print('test_assign_user success')                        
    except FortressError as e:
        self.fail('test_assign_user failed, exception=' + e.msg)
  6. Grant a permission: 
    def test_grant_perm(self):
    """
    Grant a permission to a role
    """
    print('test_grant_perm')
    
    try:
        admin_mgr.grant(Perm(obj_name='ShoppingCart', op_name='add'), Role(name="Customer"))
        print('test_grant_perm success')                        
    except FortressError as e:
        self.fail('test_grant_perm failed, exception=' + e.msg)

7. Read a user:

def test_read_user(self):
    """
    Read a user that was created earlier. Expects a unique uid that points to an existing user.
    """
    print_test_name()
    try:
        out_user = review_mgr.read_user(User(uid='foo1'))
        print_user(out_user)
    except FortressError as e:            
        print_exception(e)
        self.fail()

thows exception if user is not present

8. Search for users with a matching uid:

def test_search_users(self):
    """
    Search for users that match the characters passed into with wildcard appended.  Will return zero or more records, one for each user in result set.
    """
    print_test_name()
    try:
        users = review_mgr.find_users(User(uid='foo*'))
        for user in users:
            print_user(user)
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type user

9. Search for users assigned a role:

def test_assigned_users(self):
    """
    Search for users that are assigned a particular role.  Will return zero or more records, one for each user in result set.
    """
    print_test_name()
    try:
        uids = review_mgr.assigned_users(Role(name='Customer'))
        for uid in uids:
            print_test_msg('uid=' + uid)
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type string contain the user id

10. Search for users who have a permission:

def test_perm_users(self):
    """
    Search for users that have been authorized a particular permission.  Will return zero or more records, of type user, one for each user authorized that particular perm.
    """
    print_test_name()
    try:
        users = review_mgr.perm_users(Perm(obj_name='ShoppingCart', op_name='add'))
        for user in users:
            print_user(user)
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type user

11. Read a role:

def test_read_role(self):
    """
    The read role expects the role name to point to an existing entry and will throw an exception if not found or other error occurs.
    """
    print_test_name()        
    try:
        out_role = review_mgr.read_role(Role(name='Customer'))
        print_role(out_role)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a single entity of type role

12. Search for roles matching a particular name:

def test_search_roles(self):
    """
    Search for roles that match the characters passed into with wildcard appended.  Will return zero or more records, one for each user in result set.
    """
    print_test_name()        
    try:
        roles = review_mgr.find_roles(Role(name='Customer*'))
        for role in roles:
            print_role(role)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type role

13. Search for roles assigned to a user:

def test_assigned_roles(self):
    """
    Return the list of roles that have been assigned a particular user.  Will return zero or more records, of type constraint, one for each role assigned to user.
    """
    print_test_name()        
    try:
        constraints = review_mgr.assigned_roles(User(uid='foo1'))
        for constraint in constraints:
            print_test_msg('role name=' + constraint.name)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type role_constraint

14. Search for roles who have granted a particular permission:

def test_perm_roles(self):
    """
    Return the list of roles that have granted a particular perm.  Will return zero or more records, containing the role names, one for each role assigned to permission.
    """
    print_test_name()        
    try:
        names = review_mgr.perm_roles(Perm(obj_name='ShoppingCart', op_name='add'))
        for name in names:
            print_test_msg('role name=' + name)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of strings containing the role names

15. Read an object:

def test_read_obj(self):
    """
    The ob_name is the only required attribute on a fortress object. Will throw an exception if not found.
    """
    print_test_name()        
    try:
        out_obj = review_mgr.read_object(PermObj(obj_name='ShoppingCart'))
        print_obj(out_obj)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

return a single entity of type object

16. Search for objects matching obj_name field:

def test_search_objs(self):
    """
    Search for ojects that match the characters passed into with wildcard appended.  Will return zero or more records, one for each user in result set.
    """
    print_test_name()        
    try:
        objs = review_mgr.find_objects(PermObj(obj_name='ShoppingCart*'))
        for obj in objs:
            print_obj(obj)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type object

17. Read a permission entry:

def test_read_perm(self):
    """
    Permissions require obj_name and op_name, obj_id is optional.  This will throw an exception if not found.
    """
    print_test_name()        
    try:
        out_perm = review_mgr.read_perm(Perm(obj_name='ShoppingCart', op_name='add'))
        print_perm(out_perm)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a single entity of type permission

18, Search for perms:

def test_search_perms(self):
    """
    Search for perms that match the characters passed into with wildcard appended.  Will return zero or more records, one for each user in result set.
    """
    print_test_name()        
    try:
        perms = review_mgr.find_perms(Perm(obj_name='ShoppingCart*', op_name='*'))
        for perm in perms:
            print_perm(perm)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type perm

19. Search for perms by role:

def test_role_perms(self):
    """
    Search for perms that have been granted to a particular role.  Will return zero or more records, of type permission, one for each grant.
    """
    print_test_name()        
    try:
        perms = review_mgr.role_perms(Role(name='Customer'))
        for perm in perms:
            print_perm(perm)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type permission

20. Search for perms by user:

def test_user_perms(self):
    """
    Search for perms that have been authorized to a particular user based on their role assignments.  Will return zero or more records, of type permission, one for each perm authorized for user.
    """
    print_test_name()        
    try:
        perms = review_mgr.user_perms(User(uid='foo1'))
        for perm in perms:
            print_perm(perm)                        
    except FortressError as e:
        print_exception(e)
        self.fail()

returns a list of type permission

END
by Shawn McKinney

Testing the py-fortress RBAC0 System

The Command Line Interpreter (CLI) may be used to drive the RBAC System APIs,  to test, verify and understand a particular RBAC policy.

This document also resides here: README-CLI-AUTH

Prerequisites

Sample RBAC0 Policy

  • This tutorial covers the basics, RBAC Core: Many-to-many relationships between users, roles and perms and selective role activations.
  • py-fortress adds to the mix one non-standard feature: constraint validations on user and role entity activation.
  • The simple policy includes constraints being setup on user and role. Later we’ll demo a role timing out of the session.

Users

uid timeout begin_time end_time …
chorowitz 30min

Roles

name timeout begin_time end_time …
account-mgr 30min
auditor 5min

constraints are optional and include time, date, day and lock date validations

User-to-Role Assignments

user account-mgr auditor
chorowitz true true

Permissions

obj_name op_name
page456 edit
page456 remove
page456 read

Role-to-Permissions

role page456.edit page456.remove page456.read
account-mgr true true false
auditor false false true

 Getting Started

The syntax for testing py-fortress system commands:

clitest operation --arg1 --arg2 ...

Where clitest executes a package script that maps to this module:

pyfortress.test.cli_test_auth

The operation is (pick one)

  •  auth => access_mgr.create_session
  • check => access_mgr.check_access
  • roles => access_mgr.session_roles
  • perms => access_mgr.session_perms
  • add => access_mgr.add_active_role
  • drop => access_mgr.drop_active_role
  • show => displays contents of session to stdout

Where operations => functions here: access_mgr.py

The args are ‘–‘ + attribute name + attribute value

  • –uid and –password from user.py
  • –obj_name, –op_name and –obj_id from perm.py
  • –role used for the role name

Command Usage Tips

  • The description of the commands, i.e. required and optional arguments, can be inferred via the api doc inline to the access_mgr module.
  • This program ‘pickles’ (serializes) the RBAC session to a file called sess.pickle, and places in the executable folder.  This simulates an RBAC runtime to test these commands.
  • Call the auth operation first, subsequent ops will use and refresh the session.
  • Constraints on user and roles are enforced. For example, if user has timeout constraint of 30 (minutes), and the delay between ops for existing session exceeds, it will be deactivated.

___________________________________________________________________________________

Setup an RBAC Policy Using admin_mgr CLI

To setup RBAC test data, we’ll be using another utility that was introduced here: README-CLI.md.

From the py-fortress/test folder, enter the following commands:

1. user add – chorowitz

$ cli user add --uid chorowitz --password 'secret' --timeout 30

user chorowitz has a 30 minute inactivity timeout

2. role add – account-mgr

$ cli role add --name 'account-mgr'

3. role add – auditor

$ cli role add --name 'auditor' --timeout 5

role auditor has a 5 minute inactivity timeout, more later about this…

4. user assign – chorowitz  to role account-mgr

$ cli user assign --uid 'chorowitz' --role 'account-mgr'

5. user assign – chorowitz to role auditor

$ cli user assign --uid 'chorowitz' --role 'auditor'

6. object add – page456

$ cli object add --obj_name page456

7. perm add – page456.read

$ cli perm add --obj_name page456 --op_name read

8. perm add – page456.edit

$ cli perm add --obj_name page456 --op_name edit

9. perm add – page456.remove

$ cli perm add --obj_name page456 --op_name remove

10. perm grant – page456.edit to role account-mgr

$ cli perm grant --obj_name page456 --op_name edit --role account-mgr

11. perm grant – page456.remove to role account-mgr

$ cli perm grant --obj_name page456 --op_name remove --role account-mgr

12. perm grant – page456.read  to role auditor

$ cli perm grant --obj_name page456 --op_name read --role auditor

________________________________________________________________________________

Perform cli_test_auth.py access_mgr Commands

From the py-fortress/test folder, enter the following commands:

1. auth – access_mgr.create_session – authenticate, activate roles:

 $ clitest auth --uid 'chorowitz' --password 'secret'
 uid=chorowitz
 auth
 success

Now the session has been pickled in on file system in current directory.

2. show – output user session contents to stdout:

$ clitest show
show
session
    is_authenticated: True
    user: 
    last_access: 
user
    cn: chorowitz
    constraint: 
    system: []
    roles: ['account-mgr', 'auditor']
    dn: uid=chorowitz,ou=People,dc=example,dc=com
    uid: chorowitz
    internal_id: 552c1a24-5087-4458-98f1-8c60167a8b7c
    reset: []
    sn: chorowitz

    User Constraint:
        name: chorowitz
        raw: chorowitz$30$$$$$$$
        timeout: 30
    User-Role Constraint[1]:
        name: account-mgr
        raw: account-mgr$0$$$$$$$
    User-Role Constraint[2]:
        name: auditor
        raw: auditor$5$$$$$$$
        timeout: 5
success

Displays the contents of session to stdout.

3. check – access_mgr.check_access – perm page456.read:

$ clitest check --obj_name page456 --op_name read
op_name=read
obj_name=page456
check
success

The user has auditor activated so unless timeout validation failed this will succeed.

4. check – access_mgr.check_access – perm page456.edit:

$ clitest check --obj_name page456 --op_name edit
op_name=edit
obj_name=page456
check
success

The user has account-mgr activated and this will succeed.

5. check – access_mgr.check_access – perm page456.remove:

$ clitest check --obj_name page456 --op_name remove
op_name=remove
obj_name=page456
check
success

The user has account-mgr activated and this will succeed.

6. get – access_mgr.session_perms:

$ clitest perms
perms
page456.read:0
  abstract_name: page456.read
  roles: ['auditor']
  internal_id: d6887434-050c-48d8-85b0-7c803c9fcf07
  obj_name: page456
  op_name: read
page456.edit:1
  abstract_name: page456.edit
  roles: ['account-mgr']
  internal_id: 02189535-4b39-4058-8daf-af0e09b0d235
  obj_name: page456
  op_name: edit
page456.remove:2
  abstract_name: page456.remove
  roles: ['account-mgr']
  internal_id: 10dea5d1-ff1d-4c3d-90c8-edeb4c7bb05b
  obj_name: page456
  op_name: remove
success

Display all perms allowed for activated roles to stdout confirms that user indeed can read, edit and remove from Page456.

7. drop – access_mgr.drop_active_role – auditor:

$ clitest drop --role auditor
drop
role=auditor
success

RBAC distinguishes between roles assigned or activated and privileges can be altered in the midst of a session.

8. roles – access_mgr.session_roles

$ clitest roles
roles
account-mgr:0
  raw: account-mgr$30$$$20180101$none$$$1234567
  end_date: none
  name: account-mgr
  timeout: 30
success

Notice the audit role is no longer active.

9. check – access_mgr.check_access – perm page456.read (again):

$ clitest check --obj_name page456 --op_name read
op_name=read
obj_name=page456
check
failed

The auditor role was deactivated so even though it’s assigned, user cannot perform as one.

10. add – access_mgr.add_active_role – auditor:

$ clitest add --role auditor
add
role=auditor
success

Now the user should be allowed to resume audit activities.

11. roles – access_mgr.session_roles:

$ clitest roles
roles
account-mgr:0
  raw: account-mgr$30$$$20180101$none$$$1234567
  end_date: none
  name: account-mgr
  timeout: 30
auditor:1
  raw: auditor$5$$$20180101$none$$$1234567
  timeout: 5
  name: auditor
  begin_lock_date: success
success

Notice the audit role has been activated once again.

12. check – access_mgr.check_access – perm page456.read (for the 3rd time):

$ clitest check --obj_name page456 --op_name read
op_name=read
obj_name=page456
check
success

The auditor role activated once again so user can do auditor things again.

13. Wait 5 minutes before performing the next step.

Allow enough time for auditor role timeout to occur before moving to the next step. Now, if you run the roles command, the auditor role will once again be missing.  This behavior is controlled by the ‘timeout’ attribute on either a user or role constraint.

14. check – access_mgr.check_access – perm page456.read:

$ clitest check --obj_name page456 --op_name read
op_name=read
obj_name=page456
check
failed

Because the auditor role has timeout constraint set to 5 (minutes), it was deactivated automatically from the session.

END

by Shawn McKinney

Using the py-fortress Command Line Interpreter

The Command Line Interpreter (CLI) drives the admin and review APIs,  allowing ad-hoc RBAC setup and interrogation.  More info in the README.

This document also resides here: README-CLI.

Prerequisites

Completed the setup described: README-QUICKSTART

Getting Started

The command syntax:

cli entity operation --arg1 --arg2 ...

Where cli executes a package script that maps to this module:

pyfortress.test.cli

The entity is (pick one)

(These are source pointers to their locations in github)

The operation is (pick one):

  • add
  • mod
  • del
  • assign
  • deassign
  • grant
  • revoke
  • read
  • search

(These are just meta tags)

Argument Format

Consists of two dashes ‘- -‘ plus the attribute name and value pair, with a space between them.

--attribute_name value

if an attribute value contains white space,  enclose in single ‘ ‘ or double tics ” “.

--attribute_name 'some value' --attribute_name2 "still more values"

For example, a perm grant:

$ cli perm grant --obj_name myobj --op_name add --role 'my role'

This command invokes Python’s runtime with the program name, cli.py, followed by an entity type, operation name and multiple name-value pairs.

The above used –role is the only argument that isn’t an entity attribute name.  It’s used on user assign, deassign, perm grant, revoke operations.

Arguments as Lists

For multi-occurring attributes, pass in as a list of string values, separated by whitespace

The following arguments are lists

—phones

--phones '+33 401 851 4679' '1-212-251-1111' '(028) 9024 6609'

–mobiles

--mobiles ' 017x-1234567' '+44 020 7234 3456' '1-212-650-9632'

–emails

--emails 'f.lst@somewhere.com' 'myaccount@gmail.com' 'myworkaccount@company.com'

–props

--props 'name1:value1', 'name2:value2', 'name3:value3'

each value contains a name:value pair

Arguments as Constraint

Both the user and role entity support adding temporal constraint.

The following arguments comprise a single constraint

–-name :  label for user, i.e uid

--name foo3

For users, this can be any safe text. For role, it must already be passed in, with the role’s name.

–timeout : 99 – set the integer timeout that contains max time (in minutes) that entity may remain inactive.

--timeout 30

30 minutes
–begin_time :  HHMM – determines begin hour entity may be activated.

--begin_time 0900

9:00 am
— end_time :  HHMM – determines end hour when entity is no longer allowed to activate.

--end_time 2359

11:59 pm
–begin_date : YYYYMMDD – determines date when entity may be activated.

--begin_date 20150101

Jan 1, 2015
–end_date :  YYMMDD – indicates latest date entity may be activated.

--end_date 20191231

Dec 31, 2019
–begin_lock_date :  YYYYMMDD – determines beginning of enforced inactive status

--begin_lock_date 20180602

Jun 2, 2018
–end_lock_date : YYMMDD –  end of enforced inactive status.

--end_lock_date 20180610

Jun 10, 2018
–day_mask : 1234567, 1 = Sunday, 2 = Monday, etc – day of week entity may be activated.

--day_mask 1246

Sun, Mon, Wed, Fri

all together

cli user mod --uid someuser --name anysafetext --timeout 30 --begin_time 0900 --end_time 2359 --begin_date 20150101 --end_date 20191231 --begin_lock_date 20180602 --end_lock_date 20180610 --day_mask 1246
cli role add --name manager --description 'manager works 8-5, M-F' --timeout 10 --begin_time 0800 --end_time 1700 --begin_date 20100101 --end_date none --day_mask 1246

A Few Tips More

  • These commands have a one-to-one mapping to the admin and review APIs.  For example, the perm grant command maps to the admin_mgr.grant function and perm search –uid calls review_mgr.user_perms.
  • The description of the commands, including required arguments, can be inferred via the api doc inline to the admin_mgr and review_mgr modules.
  • The program output echos the inputted arguments and the results.

Examples

Two sections,  one each for admin and review commands.  They’re not real-world use cases but include what’s currently working although this code is, how to say it, fresh.  🙂

admin mgr

a. user add

$ cli user add --uid chorowitz --password 'secret' --description 'added with py-fortress cli'
uid=chorowitz
description=added with py-fortress cli
user add
success

b. user mod

$ cli user mod --uid chorowitz --l my location --ou my-ou --department_number 123
uid=chorowitz
department_number=123
l=my location
ou=my-ou
user mod
success

c. user del

$ cli user del --uid chorowitz
uid=chorowitz
user del
success

d. user assign

$ cli user assign --uid chorowitz --role account-mgr
uid=chorowitz
role name=account-mgr
user assign
success

e. user deassign

$ cli user deassign --uid chorowitz --role account-mgr
uid=chorowitz
role name=account-mgr
user deassign
success

f. role add

$ cli role add --name account-mgr
name=account-mgr
role add
success

g. role mod

$ cli role mod --name account-mgr --description 'this desc is optional'
description=cli test role
name=account-mgr
role mod
success

h. role del

$ cli role del --name account-mgr
name=account-mgr
role del
success

i. object add

$ cli object add --obj_name page456
obj_name=page456
object add
success

j. object mod

$ cli object mod --obj_name page456 --description 'optional arg' --ou 'another optional arg'
obj_name=page456
ou=another optional arg
description=optional arg
object mod
success

k. object del

$ cli object del --obj_name page789
obj_name=page789
object del
success

l. perm add

$ cli perm add --obj_name page456 --op_name read
obj_name=page456
op_name=read
perm add
success

m. perm mod

$ cli perm mod --obj_name page456 --op_name read --description 'useful for human readable perm name'
obj_name=page456
op_name=read
description=useful for human readable perm name
perm mod
success

n. perm del

$ cli perm del --obj_name page456 --op_name search
obj_name=page456
op_name=search
perm del
success

o. perm grant

$ cli perm grant --obj_name page456 --op_name update --role account-mgr
obj_name=page456
op_name=update
role name=account-mgr
perm grant
success

p. perm revoke

$ cli perm revoke --obj_name page456 --op_name update --role account-mgr
obj_name=page456
op_name=update
role name=account-mgr
perm revoke
success

review mgr

a. user read

$ cli user read --uid chorowitz
 uid=chorowitz
 user read
 chorowitz
 uid: chorowitz
 dn: uid=chorowitz,ou=People,dc=example,dc=com 
 roles: ['account-mgr'] 
 ...
 *************** chorowitz *******************
 success

b. user search

 $ cli user search --uid c
 uid=c
 user search
 c*:0
     uid: canders
     dn: uid=canders,ou=People,dc=example,dc=com
     roles: ['csr', 'tester'] 
     ...
 *************** c*:0 *******************
 c*:1
     uid: cedwards
     dn: uid=cedwards,ou=People,dc=example,dc=com
     roles: ['manager', 'trainer'] 
     ...
 *************** c*:1 *******************
 c*:2
     uid: chandler
     dn: uid=chandler,ou=People,dc=example,dc=com
     roles: ['auditor'] 
     ...
 *************** c*:2 *******************
 c*:3
     uid: chorowitz
     dn: uid=chorowitz,ou=People,dc=example,dc=com
     roles: ['account-mgr'] 
     ...
 *************** c*:3 ******************* 
 success

c. role read

 $ cli role read --name account-mgr
 name=account-mgr
 role read
 account-mgr
 dn: cn=account-mgr,ou=Roles,dc=example,dc=com
 members: ['uid=cli-user2,ou=People,dc=example,dc=com', 'uid=chorowitz,ou=People,dc=example,dc=com']
 internal_id: 5c189235-41b5-4e59-9d80-dfd64d16372c
 name: account-mgr
 constraint: <model.constraint.Constraint object at 0x7fc250bd9e10>
 Role Constraint:
     raw: account-mgr$0$$$$$$$
     timeout: 0 
     name: account-mgr
 *************** account-mgr *******************
 success

d. role search

 $ cli role search --name py-
 name=py-
 role search
 py-*:0
     dn: cn=py-role-0,ou=Roles,dc=example,dc=com
     description: py-role-0 Role
     constraint: <model.constraint.Constraint object at 0x7f17e8745f60>
     members: ['uid=py-user-0,ou=People,dc=example,dc=com', 'uid=py-user-1,ou=People,dc=example,dc=com', ... ]
     internal_id: 04b82ce3-974b-4ff5-ad21-b19ecca57722
     name: py-role-0
 *************** py-*:0 *******************
 py-*:1
     dn: cn=py-role-1,ou=Roles,dc=example,dc=com
     description: py-role-1 Role
     constraint: <model.constraint.Constraint object at 0x7f17e8733128>
     members: ['uid=py-user-8,ou=People,dc=example,dc=com', 'uid=py-user-9,ou=People,dc=example,dc=com']
     internal_id: 70524da8-3be6-4372-a606-d8175e2ca63b
     name: py-role-1 
 *************** py-*:1 *******************
 py-*:2
     dn: cn=py-role-2,ou=Roles,dc=example,dc=com
     description: py-role-2 Role
     constraint: <model.constraint.Constraint object at 0x7f17e87332b0>
     members: ['uid=py-user-3,ou=People,dc=example,dc=com', 'uid=py-user-5,ou=People,dc=example,dc=com', 'uid=py-user-7,ou=People,dc=example,dc=com']
     internal_id: d1b9da70-9302-46c3-b21b-0fc45b863155
     name: py-role-2
 *************** py-*:2 *******************
 ...
 success

e. object read

 $ cli object read --obj_name page456
 obj_name=page456
 object read
 page456
 description: optional arg
 dn: ftObjNm=page456,ou=Perms,dc=example,dc=com
 internal_id: 1635cb3b-d5e2-4fcb-b61a-b8e91437e536
 obj_name: page456
 ou: another optional arg
 success

f. object search

 $ cli object search --obj_name page
 obj_name=page
 object search
 page*:0
     props: 
     obj_name: page456
     description: optional arg
     dn: ftObjNm=page456,ou=Perms,dc=example,dc=com
     ou: another optional arg
     internal_id: 1635cb3b-d5e2-4fcb-b61a-b8e91437e536
 page*:1
     obj_name: page123
     description: optional arg
     dn: ftObjNm=page123,ou=Perms,dc=example,dc=com
     ou: another optional arg
     internal_id: a823ef98-7be4-4f49-a805-83bfef5a0dfb
 success

g. perm read

 $ cli perm read --obj_name page456 --op_name read
 op_name=read
 obj_name=page456
 perm read
 page456.read
 internal_id: 0dc55181-968e-4c60-8755-e20fa1ce017d
 dn: ftOpNm=read,ftObjNm=page456,ou=Perms,dc=example,dc=com
 abstract_name: page456.read
 description: useful for human readable perm name
 obj_name: page456
 op_name: read
 success

h. perm search

$ cli perm search --obj_name page
 obj_name=page
 perm search
 page*.*:0
     abstract_name: page456.read
     op_name: read
     internal_id: 0dc55181-968e-4c60-8755-e20fa1ce017d
     obj_name: page456
     dn: ftOpNm=read,ftObjNm=page456,ou=Perms,dc=example,dc=com
     description: useful for human readable perm name
 page*.*:1
     roles: ['account-mgr']
     abstract_name: page456.update
     op_name: update
     internal_id: 626bca86-014b-4186-83a6-a583e39868a1
     obj_name: page456
     dn: ftOpNm=update,ftObjNm=page456,ou=Perms,dc=example,dc=com 
 page*.*:2
     roles: ['account-mgr']
     abstract_name: page456.delete
     op_name: delete
     internal_id: 6c2fa5fc-d7c3-4e85-ba7f-5e514ca4263f
     obj_name: page456
     dn: ftOpNm=delete,ftObjNm=page456,ou=Perms,dc=example,dc=com
 success

i. perm search (by role)

 $ cli perm search --role account-mgr
 perm search
 account-mgr:0
     abstract_name: page456.update 
     obj_name: page456
     op_name: update
     roles: ['account-mgr']
     dn: ftOpNm=update,ftObjNm=page456,ou=Perms,dc=example,dc=com
     internal_id: 626bca86-014b-4186-83a6-a583e39868a1
 account-mgr:1
     abstract_name: page456.delete
     obj_name: page456
     op_name: delete
     roles: ['account-mgr']
     dn: ftOpNm=delete,ftObjNm=page456,ou=Perms,dc=example,dc=com
     internal_id: 6c2fa5fc-d7c3-4e85-ba7f-5e514ca4263f
 success

j. perm search (by user)

 $ cli perm search --uid chorowitz
 perm search
 chorowitz:0
     dn: ftOpNm=update,ftObjNm=page456,ou=Perms,dc=example,dc=com
     internal_id: 626bca86-014b-4186-83a6-a583e39868a1
     roles: ['account-mgr']
     abstract_name: page456.update
     obj_name: page456
     op_name: update
 chorowitz:1
     dn: ftOpNm=delete,ftObjNm=page456,ou=Perms,dc=example,dc=com
     internal_id: 6c2fa5fc-d7c3-4e85-ba7f-5e514ca4263f
     roles: ['account-mgr']
     abstract_name: page456.delete
     obj_name: page456
     op_name: delete
 success

END

Next up, Testing the py-fortress RBAC0 System

 

by Shawn McKinney

Distal Biceps Disruption

Last week while helping my wife load a household appliance we were donating into her aunt’s pickup was the sickening sound of my right bicep detaching itself from the elbow distal tendon.  The pain was bad, of course, but the realization of the extent of the injury was worse.  Suddenly plans of completing a 3rd consecutive DirtyKanza were nixed.  In addition to a surgical reattachment, performed yesterday, there’s several months of recovery and rehab before I can return to riding once again.

In situations like this one must focus on the positives.

  • Injury to right arm and I’m left-handed.
  • We have health insurance and can take the steps necessary for a full recovery.
  • Support of a wonderful family, friends and employer.
  • I can still code.
  • Inside trainer to maintain conditioning on order.

There’s not much value in thinking about the negatives or what-ifs.  Life has a way of throwing curve balls.  Find a way of knocking the cover off it anyway.

As far as what’s next.  I already mentioned the trainer which will be a way to maintain conditioning during the lull.

IMG_20180322_135309_552

Once the splint comes off and the brace is opened enough to hold on I am going to try and get some rides in (despite doctor’s orders) and we’ll see what happens come June 2nd.

DK200-Mud-Anon

photo courtesy of http://www.swiftwick.com/sw/cycling/kanza-does-not-care-

 

 

by Shawn McKinney

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:
admin_mgr.add_role(Role(name='customer'))

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

# Add Permission:
admin_mgr.add_perm_obj(PermObj(obj_name='shopping-cart'))
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.