XACML is dead

Conversations with vendors and IT end users at Forrester's Security lead us to predict that XACML (the lingua franca for centralized entitlement management and authorization policy evaluation and enforcement) is largely dead or will be transformed into access control (see Quest APS, a legacy entititlement management platform based on BiTKOO, which will probably be morphed by Dell into a web SSO platform).

Here are the reasons why we predict XACML is dead:

Lack of broad adoption. The standard is still not widely adopted with large enterprises who have written their authorization engines.

Inability to serve the federated, extended enterprise. XACML was designed to meet the authorization needs of the monolithic enterprise where all users are managed centrally in AD. This is clearly not the case today: companies increasingly have to deal with users whose identities they do not manage. 

PDP does a lot of complex things that it does not inform the PEP about. If you get a 'no, you can't do that' decision in the application from the PEP, you'd want to know why. Our customers tell us that this can prove to be very difficult. The PEP may not be able to find out from the complex PDP evaluation process why an authorization was denied.

Not suitable for cloud and distributed deployment. While some PEPs can bundle the PDP for faster performance, using a PEPs in a cloud environment where you only have a WAN link between a PDP and a PEP is not an option. 

Commercial support is non-existent. There is no software library with PEP support. Major ISVs have not implemented externalized authorization or plugin frameworks for externalized authorization. Replacing native SharePoint authorization with an Entitlement Management PEP is a nightmare requiring a one-off, non-standard, non-repeatable development and operations process.

Refactoring and rebuilding existing in-house applications is not an option. Entitlement Management deployment requires a refactoring of the application to use the PEP hooks for centralized, externalized authorization. This is not a reality at most companies. They cannot just refactor applications because of a different authorization model (sometimes, especially with mainframe applications the authorization model is not even understood well enough to do this...)

OAuth supports the mobile application endpoint in a lightweight manner. XACML today largely supports web based applications. While OAuth's current profiles are not a full-blown replacement for XACML functionality, we see that OAuth's simplicity made it the de-facto choice for mobile and also non-mobile applications. 

Comments

XACML is not dead

While the article highlight the fact that XACML has seen slow adoption (in enterprise) and an almost non-existent adoption by ISVs, we do see many large enterprises adopt XACML for enterprise application and services. OAuth does not compete with XACML, but rather can express a decision made by a XACML policy decision point (PDP). OAuth doesn't specify the policy language and evaluate policy requests against a policy. It is a way to convey in a trusted manner a decision (not make the decision). I think the claim that XACML is dead will prove to be incorrect. Unless there's a viable alternative to the XACML language, it will remain the lingua franca of authorization. I was the CEO and founder of BiTKOO and now chief software architect at Dell where the product (Authorization Policy Server - APS) is alive and well and is a strategic component of our identity and security portfolio. The product is built on XACML version 3.0 and based on its adoption and what we hear from customers, the article is incorrect on almost all levels.

There is nothing in XACML that requires or assumes all users reside in the same AD domain. Actually, XACML doesn't have any user identity requirements - XACML can be used without any knowledge of the user identity at all, depending on how you design your policy system the PDP can inform the PEP why a request was denied using XACML Advice notations in the response.

PDPs can be easily cloud hosted and widely distributed because the PDP is stateless. It doesn't matter which PDP the PEP talks to if all the PDPs are running the same policies

Mark Twain and Kerberos were dead too.

Standards adoption is always slow and often needs a catalyst. With networking, the “internet” stopped the debate – it’s TCP/IP. Kerberos was also dead, many times. Then Microsoft produced AD, and the chaotic world of NT became orderly, and my company Vintela (bought by Quest, now Dell) decided to standardize the way ALL Unixes worked with AD and Kerberos. The rest of the world followed and now we do not think about it. SOX helped a lot. I agree with Doron, the adoption IS slow, but the answer is not Oath on its own. We need corporate adoption of the cloud, and less security; less control, lower thresholds of policy is not the answer. Maybe migrations to Azure might start the process? WAAD, Sharepoint online, excel online are all tempting tools to push corps to use these cloud services - but you MUST wrap policy around your activity and it MUST be standards based.
We’ll get there.

Doron, David: thanks for your comments

Doron, David: thanks for your comments.

While XACML is a great engine for policy evaluations and management (see Quest's move to use it for APS), we don't see the PDP/PEP authorization model scale to legacy applications and distributed, non-hardcore enterprise applications. I think of XACML as an empty envelope or standard which today lacks the love letter of the industry adoption. Adoption has always been slow, even when XACML for Entitlement Management was the only really viable choice. XACML adoption is even slower now that we have emerging and much simpler alternatives like OAuth, UMA, etc.

We have been tracking XACML at Forrester since 2008. We are fielding less than handful of inquiries a year on XACML - and I don't think it's because everyone figured out how to put the PEP into their Cobol or COTS or refactored or cloud application.

(Side note: AD and Kerberos are also dying. SaaS (SFDC, Google, etc.) and Cloud IAM identity stores and Federated authentication protocols are taking over. But I agree with you that they at least had some useful life.)

XACML - what is the alternative

Andras,

Do you recommend to customers to hard-code authorization logic into their new enterprise services and applications? If not, what alternative to XACML is there?

We see organizations continue

We see organizations continue to use their existing frameworks or keeping authorization within the application. It is not a recommended practice, just reality. If XACML was *much* easier to implement, and extended with federation capabilities, it would have a chance.

XACML Wobbling

Andras;
Great a thought provoking Blog Post. I definitely don't believe that XACML is dead, but it is wobbling, but as Gartner points out Externalised Authorisation is going into the trough of disillusionment. Of course like Doron, my company supplies an XACMLv3 Policy engine product - ViewDS Access Sentinel, however we have gone one step further by also implementing Policy based Access control using XACMLv3 into our core Directory Engine itself - ViewDS where XACML is being used to control access to On Line Directory services. Our product ViewDS is in use in more than 20 countries worldwide (for instance Underpinning Air Traffic control systems in many countries including the recently awarded Eurocontrol project) and all these users of our Application" get the use of Policy Based Access control using XACMLv3 in the latest release of ViewDS). ViewDS is also extensively used itself in the Defence & Intelligence community. All these sectors are ones where providing better access and authorisation is becoming super critical to stop more Wikileaks disclosures. We are doing very interesting work in this field in the Government & Defence sectors combining Document security (rendition triggered by Obligations and Document control). In fact if you or others are attending the EIC Conference in Munich (May 14th- 16th) next week do come along to Exhibition Booth S3 where we will be exhibiting as Silver sponsors. In addition to providing demonstrations of our ViewDS Directory Server and Access Sentinel XACML-based entitlement management systems, we will be sharing the results of our recent collaboration with TITUS Software.

Our collaboration combines Access Sentinel and TITUS SharePoint Security to create an XACML-based fine-grained authorization solution for on-premises SharePoint. This joint ViewDS identity Solutions offering with Titus Software will demonstrate how the dynamic and flexible authorization policies of Access Sentinel can enhance security and compliance while simplifying management of SharePoint access controls.

On Doron's and David Wilson point ref Cloud Hosted. We already have one cloud vendor using our product and because our solution is Directory centric we use standard protocols to overcome the issues of distribution of authorisation policies. We have also taken the step by not being hi bound only to our ViewDS Directory server by also supporting the ability to call out to other LDAP and non LDAP Identity sources such as AD, Novell eDirectory and products such as Radiant Logic Virtual Directory solution and Oracle Virtual Directory since the reality is in most enterprises identity attributes sit in multiple silos. We also provide an off the shelf integration with our partner Ping Identity offering a combined Authentication and Authorisation solution. So yes, large scale adoption has not happened yet, but adoption is growing. Bear in mind as well that XACMLv3 was only ratified just this year.
Andrew Ferguson

XACML is dead because the

XACML is dead because the use-cases it solves for were never understood by the industry analysts who have journalism backgrounds. Let's face it, only the few and far between analysts that come from practitioner backgrounds can understand the potential value proposition that entitlements management can provide in improving the security posture of enterprise applications.

If analyst firms actually dug deep into use-cases instead of vendor revenue comparisons and easily gathered information via surveys, XACML would have been a commercially viable standard.

XACML is Growing Up

This conversation reminded me of a similar debate we had here at NextLabs over eight years ago. In 2004, XACML was dead. I think there was one commercial product. But the security market was starting to shift its focus from securing the network and applications to securing the data (for example the early DLP companies were getting traction). It was clear that the model companies used to secure their data was so manual and inflexible that it would never scale to meet the demands of future regulations, mobility, cloud, and hyper collaboration. So the big idea: “What if you could write a policy about how your information should be protected and it would be enforced universally?” An obvious good idea and a hard problem – Sign me up!

So we needed a policy language and it needed to have a couple of key characteristics:

1. Application and Vendor Independent
There are hundreds of examples of products that have great policy management, but all of these only work for a single product or vendor. When data exists in many applications, this same data moves from one application to another. Today, these applications may be in your data center, in the cloud, or on any number of mobile devices. So, it is critical that the policy be flexible enough to be application independent.

2. Attribute Based
The number of data resources within an organization is massive (think data warehouse), it is constantly increasing (think email), and its growth is accelerating (think collaboration). The only scalable way to apply policy to data resources across applications is to describe the data, using attributes. Attribute Based Access Control (ABAC) is a model that has been around for a while and it is required to apply policy to data.

3. A Standard
The average large organization has thousands of applications from a hundreds of vendors. To achieve the universal dimension of our vision, we needed a standard based policy language so that over time the market might move to a model, where application vendors would support the standard, just like we did for LDAP and SQL before that.

Based on these requirements we chose XACML, and when I compare it to 2004 it would be hard to argue that XACML is dead today. Not only are there dozens of products and ever new products coming to market, I have six enterprise wide deployments going live this week and our business grew 300% last year. XACML continues to get more compelling.

I will concede this. The strategy of selling XACML as a generic policy engine doesn’t work. Most of the products have matured to hide the complexity of XACML and the marketing now communicates a business-level value proposition. I can see how this might look like the death of a market, since a company using one of the XACML-based products out there today may not even know or care that it is based on XACML. To me that is proof that XACML has grown up. Today we are solving real business problems, delivering real applications, and articulating out-of-the box business value.

Andy Han
/originally posted on www.nextlabs.wordpress.com

Article is completely confused

This article makes so many confused and ill-informed claims that its hard to know where to start.

PDP does a lot of complex things... and so does any access controller such as your computer login screen. A PDP's job is to render an access control decision, period, not to explain why a decision was negative which can easily leak information to attackers. That's a job for the help desk, which can consult logs that may provide helpful details.

Not suitable for cloud and distributed deployment.

"Bundling the PDP with the PEP" violates the goal of separating enforcement from decision-making in pursuit some vague goal of "improving performance" and loses the advantages of separating these functions. Separating them allows different PEPs to be developed for different resource types (web, sharepoint, ...). But most of all, why not put the PEP where it belongs, in the cloud near the resources its guarding?

There is no software library with PEP support because no library support is needed. If an application communicates with a web resource successfully today, it communicates with that resource when its guarded by a PEP in exactly the same way, with an ordinary HTTP request. The PEP is essentially a proxy that just adds an access control feature, either returning a successful response if the decision is permit or a fail if the decision is deny. Exactly the way ordinary Http requests work.

Replacing native SharePoint authorization with an Entitlement Management PEP is a nightmare requiring a one-off, non-standard, non-repeatable development and operations process.

Yes, its a pain, and that's Sharepoint's fault. It uses its own idiosyncratic ACL-based access control system in which URL's (resource locators) don't clearly identify resources, is a foundational XACML concept. Nonetheless we managed to build a Sharepoint PEP that works quite successfully by surmounting this issue.

OAuth supports ... a lightweight manner.

I defer here to recent "OAuth is dead" articles, particularly one by OAuth's very disillusioned author for quite another view. This may have once been true for OAuth 1.0 but "lightweight" is certainly not true for OAuth 2.0. The new standard's vagueness surpasses even XACML.

Not dead yet, but dying...

The points you raised were interesting and I believe valid. It is a shame hardly anyone with a different view on the matter tried to address them specifically.

"It isn't dead because I have a product" misses the point; so does "what else is there?"

Not dead yet, but dying...

The points you raised were interesting and I believe valid. It is a shame hardly anyone with a different view on the matter tried to address them specifically.

"It isn't dead because I have a product" misses the point; so does "what else is there?"