Open Site Navigation
  • Shawn McKinney

Who put ABAC in my RBAC?


Readers know that Attribute-based Access Control (ABAC) is a bit of an obsession with me. It stems from the want to have something like an ABAC system in my little bag of tricks. An authorization engine that scales to everyday usage, without proprietary, bloated or cumbersome baggage to weigh it down.


So I comment, lament and nothing seems to come of it.

Until I leaned that ABAC can be combined with RBAC.

We like RBAC, use it in our everyday applications, but it has some serious shortcomings, and we don’t know what to do about them.

ABAC also good. It’s adaptable, but lacks meaningful standards, we struggle during implementations, and are left wanting more.

Now, let’s somehow combine the two. Hopefully allowing the strengths of each to be preserved while eliminating their shortcomings.

What would such a system look like?

  1. Simple apis that are easy to understand and use.

  2. Standard data and api formats, something that can be shared between all of my apps and systems.

  3. Flexible decision expressions allowing unlimited instance data types and values to be considered.

How would this system work?

Standards-based RBAC adheres to the NIST model, later becoming an ANSI standard — INCITS 359. Long story short, RBAC allows attributes to be applied during two separate phases of the access control decision:

1. User-Role Activation – instance data used to constrain whether an assigned role is eligible to be considered in the access control decision, i.e. permission check, that happens later. For example, user may only activate the cashier role at store 314.

2. Role-Permission Activation – these constraints apply during the permission check itself. An example is the action may only be performed if account #456789.

Apache Fortress 2.0.2 now supports type 1. For a test drive, there’s this rbac-abac-sample in Github. Have a look under-the-hood section of the README.

43 views0 comments

Recent Posts

See All

Jan 17, 2022 Introduction Symas OpenLDAP configured with LMDB has been extensively tested and its performance characteristics are well understood. Both OpenLDAP and LMDB’s scaling characteristics are

Please note that the certificates must be in a pem format (.pem or .crt). You will need three certificates: Root CA certificate, server certificate (with the fqdn of server in subject line or in the s

  • Symas Blog RSS Feed
  • Symas on Facebook
  • Symas on Twitter
  • Symas Blog
  • Symas on LinkedIn
  • Symas YouTube Channel

Copyright © 2022, Symas Corporation. All rights reserved. Privacy Statement (updated July 28, 2022)

Phone:

Main Office: +1.650.963.7601
Fax: +1.650.390.6284

Email:

Sales: sales@symas.com
Support: support@symas.com

Office Hours:

8:00 AM - 5:00 PM ET

Office Location:

Symas Corporation
PO Box 391
Grand Junction, CO 81507 USA