It’s always great to catch up with Gunnar Peterson and discuss the latest in externalized authorization. There was quite a bit of ground to cover since our last blog post series and here is the transcript:
Gunnar Peterson:
The thing that strikes me about XACML and ABAC is that its really different from other security standards. Usually when we talk about an authentication or crypto protocol, we talk about strength, threat models, and the strength of the security service itself. It’s inward focused. It seems to me that the value of XACML and ABAC is really in the use cases that they enable. It’s outward focused, and unlocks value through new kinds of services. What kinds of use cases have you seen recently where XACML and ABAC are enabling companies to build things better?
Gerry Gebel:
You are correct to point out that XACML feels different from other identity and security standards. XACML is inwardly focused on the application resources it is assigned to protect through the use of its policy language – there isn’t just a schema, token format or DIT to work with.
There are a couple of recent customer use cases that I’d like to briefly describe as they are typical of the kind of requirements we see. In the first case, the organization holds a lot of data for customers in different industries and they wish to provide access to different slices of data via a combination of APIs and web services. In this case, its API access primarily for mobile devices and web service for other client applications. Specific business rules dictate what data customers can view or what APIs/web services they can call. Integrating an XACML service at the API/web services gateway layer is a non-intrusive way to implement the right level of data sharing and enable new business models for the organization.
The other case study example is for an organization that is building a new data hub service, where certain users can publish data to the hub and others will subscribe to the feeds. Due to the sensitive nature of the information, granular access control was important for the new service. In this case, the designers wanted a flexible policy-based model to control access, rather than hardcoding it into the application.
GP:
Interesting use cases, let’s drill down on these. First as to the gateway – I am a fan of web services gateways, they are a no brainer for implementing identity, access control, dealing with malicious code and so on. Authorization (beyond coarse grained) requires a little bit more thought. How have you seen companies approach getting the right level of granularity to take advantage of the XACML Policies at a gateway level? In other words, given that a gateway has less context than the application layer, what is the hook for the policy to be able to intelligently make authorization decisions outside the app as it were?
GG:
You are correct to point out that you can only make as granular an access decision as the context that is provided to the policy decision point (PDP). In this case, the call from the gateway to the PDP may just contain something like: subject: Alice, action: view, client_record: AD345. The PDP can enhance the situation by looking up more information about Alice before processing the access request – her department, role, location, etc. In addition, the PDP can look up information about the client record – is it assigned to the same location or department as Alice. With this approach, you can still make pretty granular access control decisions, even though you don’t have a lot of context coming in with the original access request from the gateway.
GP:
Right, so its case of Roles are necessary but not sufficient?
GG:
Roles are usually only part of the equation and certainly not adequate on their own for granular authorization scenarios.
GP:
Here is one I wrestle with – naming. On the user Subject side its pretty simple, we have LDAP, we have AD, and everyone knows their user names and log in processes, but what about the resource side? Its seems less clear, less consistent, and less well managed, once you get beyond URL, URI, ARN and the like. What trends are you seeing in resource naming and management; and how does this effect XACML projects?
GG:
Indeed, naming conventions and namespaces for subject attributes are prevalent and are lacking for other attribute types, in particular for resources. One approach to address naming for resources is to publish an XACML profile, whereby you can establish standard names for at least a subset of attributes. We see this being done today in the Export Control and Intellectual Property Protection profiles. Some firms in the financial services industry are also examining whether XACML profiles can be defined to support certain cross tim interactions, such as trade settlement.
Otherwise, ABAC implementers should approach this task with a consistent naming convention and process to ensure they end up with a resource namespace that is manageable to implement and operate.
GP:
I had always looked at XACML as something that helps developers, but it appears to have a role to play in areas like DevOps too. I have seen a few examples where XACML services delegate some administrative functions, such as spinning up Cloud server instances, and lower level configuration. For decentralized environments where admin tasks (which are very sensitive and need to be audited) can be handled by different teams and even different organizations this kind of granular policy control seems like a very good fit. It gave me a new perspective on where and how XACML and ABAC might fit, have you seen these types of use cases?
GG:
Normally we are dealing with application resources, but we have had cases where IT uses XACML to control access to DevOps kinds of functions. As you have pointed out, the XACML policy language can be quite useful in a number of areas where granular access control is important.
GP:
Developers and security people fundamentally lack good (read: any) testing tools for authorization bugs. Static analysis and black box scanning tools are all the rage (and server a useful purpose in security bug identification), when you scan your app they can find all manner of SQL Injection, XSS and other pernicious problems, but at the same time you can cut those same tools loose on an app that’s riven with thousands of authZ vulnerabilities and they will often come back green! I am pretty sure this is a major factor contributing to the numerous authorization vulnerabilities we see.
I think even just a first cut, 1.0 implementation with XACML and ABAC is an huge leg up towards formalizing some of the authZ structure so that real test cases can be developed and run. This makes it simpler for the developer to avoid authZ mistakes since they can continually test against a defined policy instead of dumb scanning against something where your tools cannot differentiate between what’s authorized versus unauthorized states. What are your thoughts on authZ testing?
GG:
We get a lot of questions about testing the policies in an ABAC system and there are many ways to address this requirement.
1. At the policy authoring stage, there is the requirement to perform initial unit testing – does this policy I am writing operate the way I expect it to? We provide this simulation capability so you don’t have to run the application to see outcome of a policy and it includes a trace facility so you can explore exactly how the policy was evaluated (this is a big help in debugging policies as well). Unit tests can be captured in scripts for future use, such as when the application or access policies change.
2. Positive and negative test cases: You are correct to point out that developers can test against a defined policy, such as: cardiologists can view and update records of heart patients. We refer this as a positive test, that is, does the policy allow doctors that are labeled cardiologists to view heart patients’ medical records? But there are other conditions to test for that may be characterized as negative tests. For example, given a set of ABAC policies, is there any way a non-cardiologist can update a heart patient’s record? For these kinds of scenarios, you can build additional test scripts or use an advanced policy analysis tool.
3. Gap analysis testing: Another advanced function is to test for any possible gaps in the policy structure. But again, as you pointed out, having a specific set of access policies to test against makes the process easier. In this manner, you could test for separation of duty scenarios that violate policy: is there any combination of attributes that permits a user to create and approve a purchase order?
GP:
In my opinion, there are concrete benefits from being able to make more granular authZ decisions, audit policies and configure rather than code authZ, but as a security guy the testing piece all by itself is a game changer. This is just such a big gap in so many systems today and a large source of “known unknown” kind of bugs, ones that can be but often aren’t found and closed.
Ok last question – is XACML dead? This is your cue to tee off.
GG:
Far from it. I’ve witnessed a significant increase in demand for XACML solutions over the last few years, the OASIS technical committee <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml> is actively working on new profiles (after version 3.0 of the core spec was formally ratified earlier this year), and seen new vendors enter the market. There is a big emphasis to further improve the standard for consumption by the developer community, a key constituency if the industry is going to escape the cycle of hard-coding authorization inside applications. Some of the standardization efforts worth noting are profiles to define a REST interface for the authorization service as well as JSON encoding of the XACML request and response formats. These two enhancements should greatly broaden the appeal of the XACML authorization standard. Further, Axiomatics recently joined the OpenAz <http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page> project to help update and improve this developers’ API.
