Like any other community out on the web today, the security community has no shortage of acronyms to toss around about their technology of choice: PCI DSS, SAML, NIST, XACML...just to name a few. These standards have also helped shape products and platforms to help keep applications and their users (and those users' data) safe from prying eyes.
This particular article is talking about just one of the technologies in this jumble of alphabet soup - XACML. XACML, or the Extensible Access Control Markup Language standard, helps to define XML-based structures that can be evaluated - language agnostic - to check if a given users (the standard calls them Subjects) can access a given Resource. At its most basic level, XACML is a set of attributes and matches that are compared when the Resource is requested and a verdict of PERMIT or DENY is passed down from the Decider and Enforcer dynamic duo.
The goal of the XACML standard is to provide a common language that applications, regardless of the language their code is written in, can communicate about the allowed actions on a resource. While not the simplest thing in the world, it does provide a good and verbose structure for abstracting out the Policies to restrict access. It's attribute-based, removing any notion of normal ACL (Access Control List) structures or custom permissioning that the calling application might have to know about. Instead it abstracts it out to match the attributes and their values from the policies against ones in the Request, Subject, Action and Environment to see if they're allowed. XACML is all about authorization not authentication, so don't look to it to help you validate a user is who they say they are. It only knows what you give it, so you'd need to have the attributes for the Subject before even making the request.
So, by now you've noticed several terms that have been emphasized - these are all keywords in the OASIS XACML standard that help shape this common language. I'm not going to get into the same depth they do in the spec, but here's some of the most common terms and their meanings:
These are just a few of the many terms that the OASIS specification uses, so I'd encourage you to give it a look and investigate them all to help it all make sense.
Now that we've covered some of the basic concepts and terms behind this process, let's look at the actual flow of information and how things are evaluated. Stick with me on this - it's not the simplest thing to follow, but I'll try to make it as clear as possible.
This is a pretty basic evaluation flow. There's lots of other things that could go into it, but it's just easier to start simple and work your way up.
As a part of my research on the subject, I worked through creating a PHP-based library to help with the Policy creation and evaluation. I've posted it over on Github for you to check out if you're interested.
I've pulled out the example from the README to show the usage of the library and dropped it in here. I've broken it down in the inline comments to help explain things a bit. This example assumes that you've installed it
` <?php require_once 'vendor/autoload.php'; // Create our Enforcer and Decider to handle the evaluation $enforcer = new \Oasisphp\Enforcer(); $decider = new \Oasisphp\Decider(); $enforcer->setDecider($decider); //------- Start creating our Policies /** * Create some Matches for "property1" * one for the string "test" and another for string "test1234" */ $match1 = new \Oasisphp\Match(); $match1->setOperation('StringEqual') ->setDesignator('property1') ->setValue('test')->setId('TestMatch1'); $match2 = new \Oasisphp\Match(); $match2->setOperation('StringEqual') ->setDesignator('property1') ->setValue('test1234')->setId('TestMatch2'); // Create a Target container for our Matches $target = new \Oasisphp\Target(); $target->addMatches(array($match1, $match2)); // Make a new Rule and add the Target to it $rule1 = new \Oasisphp\Rule(); $rule1->setTarget($target) ->setId('TestRule') ->setEffect('Permit') ->setDescription( 'Test to see if there is an attribute on the subject' .'that exactly matches the word "test" or "test1234"' ) ->setAlgorithm(new \Oasisphp\Algorithm\DenyOverrides()); /** * Make two new policies and add the Rule to it (with our Matches) * Both of the policies have the same Rule attached */ $policy1 = new \Oasisphp\Policy(); $policy1->setAlgorithm(new \Oasisphp\Algorithm\AllowOverrides()) ->setId('Policy1') ->addRule($rule1); $policy2 = new \Oasisphp\Policy(); $policy2->setAlgorithm(new \Oasisphp\Algorithm\DenyOverrides()) ->setId('Policy2') ->addRule($rule1); //------- End creating our Policies /** * Create the Subject with its own Attribute * (the one we're wanting to match) */ $subject = new \Oasisphp\Subject(); $subject->addAttribute( new \Oasisphp\Attribute('property1', 'test') ); /** * Make the Resource and link the policies to it */ $resource = new \Oasisphp\Resource(); $resource ->addPolicy($policy1) ->addPolicy($policy2); /** * Finally, we evaluate the subject and resource with the * Enforcer (PEP) to see if they have access */ $environment = null; $action = null; $result = $enforcer->isAuthorized($subject, $resource); /** * So, because the Subject has the "property1" Attribute and it's * set to "test", the $result is true */ echo "\n\n".' END RESULT: '.var_export($result, true); echo "\n\n"; ?>
One thing you'll note is that in the example above there's no concept of Action or Environment like there is in the spec. This was just to keep things simple. As a base-level sort of evaluation, only the Subject and Resource are really needed. The Action is probably next in importance with the Environment being last (given that it's mostly just a set of extra values to give the Decider).
While the goal behind XACML is a good one, like many XML-based standards it might be a bit too complex for its own good. It's almost one of those "too flexible" kind of situations and can easily cause confusion if you're not paying attention.
Should you implement it in your systems? Like many topics in technology (and security specifically) it gets a resounding "it depends" kind of answer. There's other technologies out there (like OAuth) that can achieve some of the same goals with a bit less complexity and some other advantages. Still, if you're in a situation where a company or group wants to integrate with you on a more general level, XACML may be worth a look.
With over 12 years of experience in development and a focus on application security Chris is on a quest to bring his knowledge to the masses, making application security accessible to everyone. He also is an avodcate for security in the PHP community and provides application security training and consulting services.