I’ll Be ABAC

Remember the first time you used an admin flag to expose a special feature in your software? Pretty cool. Remember the first time you had to pee so bad during a game of hide-and-seek that you stood up behind the wood pile where you were hiding and went for it just as you were being found and the finder ran inside and told all the adults and they laughed at you which caused you to have pee anxiety for the rest of your life? Pretty not cool. Back to the point.

Admins and users, the halcyon days. Admin feature? No problem, just check the admin flag. Regular user? NO SOUP FOR YOU! Simpler times. Over the last few years I have been working on complex permissioning systems for web applications (among other things). Thankfully my Open Source software Cypht, being a sort of old school web app (but also new!), is just users and admins. And admins have very little special sauce. Easy-peasy.

However my bill-paying gig requires fine-grained access rights. In between tangents I’m going to talk about it, because like all shitty software tasks, it eventually ends up on my desk. And like all shitty software tasks, you will have to wade through some super boring domain knowledge to figure things out. We started as a team re-rolling the same system we half-ass implemented in the past, only to realize it’s not good. This led us to think there just may be a third-party solution that would ease the pain and make our system better.

In my ever so humble opinion, third-party solutions NEVER ease the cumulative pain, they only move the pain-ball around to different pain-regions. The system we landed on implements what is known as ABAC, or Attribute Based Access Control. It uses XACML, which is a … weird specification. XACML is both a protocol for enforcing access to a resource, and a system architecture. Like all good specifications it uses XML for data transfer *snort*. More importantly, it renames common operations and parts of the system with unique acronyms so nobody really knows what you are doing or even talking about.

Take this statement for example:

Not sure why the policy request from the PEP for that particular resource and action pair returned indeterminate, so I will have to inspect the PDP to see if it has a problem accessing the PIP to enrich the relevant attributes, as well as verify the request XML from the API. End of line.

This actually makes sense based on the ABAC system I’m working with (except I know that indeterminate responses mean there is no corresponding policy to evaluate the supplied resource and action, so I would never actually say this, but somebody else might, so it’s legit). Also I only say “End of line” in my head after I finish speaking.

We had high hopes the ABAC system would save us silver-bullet style from slogging through building our own. It didn’t. But it is pretty cool. In no particular order, here are some things to consider if you are thinking about implementing an ABAC system, third-party or otherwise.

  • XACML systems only issue permit/deny/WTF responses. This is important so don’t skip this bit. You DON’T ask the system “What does Jason have access to?“, you ask it “Does Jason have access to X?“. It’s a critical difference. X can be a list of things, but keep in mind the longer that list, the more time it will take the system to respond.
  • When deciding if a user can access something, XACML systems can be tied into your standard run of the mill RDMS. In the XACML world, this is called “attribute enrichment from the PIP” – where the PIP (Policy Information Point) is the RDMS.
  • I would very much like to throat punch the person who coined the phrase “attribute enrichment”
  • It’s XML all the way down peeps. The request, the response, even the policy used to say yay or nay in the ABAC system. It’s also super verbose with ample namespace usage. Good times indeed!
  • Using an XACML ABAC system does provide a nice separation of concerns. User roles and rights can still be defined in a RDMS, but they are enforced by the ABAC system. This aspect I very much like.
  • The “resources” used in policies, AKA, what you want access to, have a hierarchy. This allows for a cool fallback to a more generic policy if the specific one requested does not exist. And in the other direction, provides a mechanism to create a one-off policy for a special use case. This I also very much like.
  • Just to re-iterate – If you are looking for a system that provides a list of things a user has access to – ABAC over XACML is not that system. It can kind of sort of be shoe-horned to do that, but it’s hacky at best, and does not scale for shit.

Well there you have it. ABAC/XACML is cool, has some neat features, uses crappy formats, invents its own dialect, and overall is boring enough that I hope you never have to work with it. Next in my new series of “Esoteric software related posts that nobody could possibly find interesting“, I’m going to talk about switching out the terminal emulator I have been using for the last decade. Oh snap, I already did that one.

Either way, you have to love the “I’ll be ABAC” title pun. Pure comedic gold that one. Hasta la vista, baby!

One thought on “I’ll Be ABAC

  1. “Like all good specifications it uses XML for data transfer *snort*.”

    The “self-describing” XML data makes the response 5x larger than necessary and I can heat my office with my CPU as it parses that XML. Perfect!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s