Posted tagged ‘XACML’

Talking about authorization w/ Gunnar Peterson

June 10, 2013

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&gt; 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&gt; project to help update and improve this developers’ API.

XACML – so much more than some people can see!

June 29, 2011

This is Felix Gaehtgens and I am one of the latest additions to the Axiomatics team. My colleagues Gerry Gebel and David Brossard were so nice to offer me a space on their blogs. As a former industry analyst, I’m going to start here, and post my future more technical musings on David’s blog.

Speaking about musings, I just stumbled upon an article on heise.de from my former colleague Martin Kuppinger. The article talks about access management with the XACML standard and is entitled “Only good if you can’t see any of it”. It is published in German, and if you can understand that, you can read it here. Martin is a distinguished and very smart analyst, and I am honoured to have worked alongside him for more than three years at Kuppinger Cole where I covered the authorization field and in particular the XACML technology. His past and current musings – apart from this one article – provide an excellent insight into the current state of technology within the Identity and Access management field.

In his article, Martin wrote that XACML is a complex language. He expects that companies implementing XACML will have to confront a large set of many complex rules, and therefore the management of these rules is complex. He makes the point that XACML has to be “hidden” by tools because it is just too complex to use.

To my experience, nothing is further from the truth. This merely reflects some common misconceptions about XACML, and it also reflects some FUD (fear, uncertainty and doubt) floating around by some people without sufficient understanding of the XACML technology. What is important here is that customers need to have fully-fledged XACML tools to solve their complex authorization problems. Cutting corners and then calling those limited features “simplification” to make it “more user-friendly” mean that you don’t get all of the powerful benefits, and shouldn’t be an option for you. You need the potential of this technology to tackle the hard authorization problems in the real world. You will need to use the concepts of XACML to create compact and adequate policies. No short-cuts are recommended here.

XACML is a language used for access control, and it is very powerful and flexible. When I compare it to simple rules used in traditional SSO and RBAC-like access management products, I like saying that RBAC is like a simple text editor and XACML is like a word processor. If your needs are really simple then perhaps a text editor is enough. But if you want to create real documents, I’d highly recommend using a word processor.

The reality in XACML implementations is that you create a small set of policies that quite accurately reflects the overall business requirements. In many cases, you can almost “translate” a business access control requirement into one policy. This makes things quite simple, because you can easily edit the few number of policies to make sure that they accurately reflect what the business is demanding.

I’ve seen this already “at work” with several of our customers. They are really enthusiastic about the fact that they can create a fairly simple policy model in XACML to link their business policies together with data that already exists in the enterprise and deploy truly powerful and dynamic access control for their applications. It’s very cool to see this in action. That’s why I really disagree about the “good practise” of “generating” XACML from “simple” rules. Sure, you can do that, and there may be some cases when this could be useful, but then you are really missing out on those benefits of XACML that can truly transform your deployment.

Consider the other, more “traditionalist” approach. You have primitive and “simplified” access control rules, often in the form of “if user X has role Y”. You then need to model your business requirements in these types of low-level rules. Not an easy task, and it also means that you will need to maintain a whole new data repository to support your simplistic policy model. That is complex. And that is much more difficult to maintain and audit.

So XACML is “expressive” and “complete” rather than “primitive” because it allows you to do many more things. It allows you to define your access policy in just a few well-defined rules that are not difficult to understand, rather than in a myriad patchwork of primitive access control statements that become difficult and expensive to maintain and audit. This in my opinion is one of the greatest benefits of XACML. Maintaining you access control system in XACML makes it much easier, rather than more complex.

When I started at Axiomatics, I already expected that our customers would find it easier modeling their access control requirements with XACML rather than using a traditional role-based approach. Once I started talking to them, I was somewhat surprised to find out that many of them found it even easier than I thought! Sure, you have to learn a little (not too much), but this usually saves you so much more time and money because if elegantly side-steps a lot of the mess that you would otherwise have to confront.

Where Martin does have has a point is that XACML is based on XML, and nobody (except maybe for some hard-core geeks) would like to maintain XACML policies by editing raw XML files. But that’s obvious. At Axiomatics, we ship a GUI (graphical user interface) that allows you to define and test your XACML policies. It offers the full power and features of XACML in an easy way, rather than a limited “simplified” subset of possibilities that don’t go far. The learning curve with XACML is not steep, because it is actually very natural in the way that it allows you to express your requirements; and as with any powerful tool you’d be advised to take a bit of time to learn about the features at your disposal and real-life good practises that we’ve learned from our customers’ experiences. I’d be happy to discuss them with you – just drop me an email.