Forrester analyst Andras Cser has proclaimed XACML is Dead.
Unfortunately, the data used to justify this proclamation is flawed at many levels.
Disclosure: I am the architect of the XACML 3.0 PDP authorization engine at the heart of the Dell/Quest Authorization Policy Server product, and I am a member of the OASIS XACML technical committee. I am a Dell employee, but the opinions stated here are my own, not my employer’s.
Cser writes:
Lack of broad adoption. The standard is still not widely adopted with large enterprises who have written their authorization engines.
Setting out to write your own authorization engine makes as much sense as writing your own operation system or your own encryption algorithm. Authorization is a complex topic. Rolling your own security system for each application is not a good use of resources, nor a good approach to security in general. For businesses savvy enough to recognize this, there is no shortage of capable authorization engine products available on the market today, most of which support XACML either natively or through an interop transform.
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.
Wow. Where’d that come from? XACML has absolutely nothing to do with Active Directory, nor user identity in general. I’ve helped customers design XACML policy systems that weren’t dependent upon user identity at all.
A business can write XACML authorization policy rules that test for user identity metadata such as roles, group membership, or attribute values stored in Active Directory. If the business runs multiple AD domains, then they should be careful to write their policy logic in a way that spans their AD domains.
A better solution would be to move away from the central directory model into a claims based model so that the XACML policy rules evaluate security claims about the user submitted with the authorization request. SAML is one mechanism to securely convey user claims. OAuth can carry user claims as well, via token formats such as JWT. When user attributes and claims are presented with the user identity in a XACML authorization request, the XACML PDP can make fine-grain authorization decisions involving user identities from different domains of control. The PDP need only trust the issuer of the user attributes and claims and verify that the cryptographic signature on the user data comes from a trusted issuer.
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.
XACML does provide a mechanism for the PDP to communicate such information to the PEP – Advice. All the business security officer writing policy has to do is attach an Advice element to a policy rule to return information or messages to the PEP and application. Example: If the disk-quota-exceeded rule evaluates to Deny, an Advice element attached to the rule can return a message to the PEP like “You have exceeded your disk quota of {N} MBytes.”
Other responses to this criticism of the tight-lipped PDP returning only a terse Permit or Deny authorization decision:
- “It’s none of your business”
- “That’s classified”
- “It’s not the PEP’s role to ask why. It asks for permission, it gets a Permit or Deny.”
- “The decision involved other people’s personal data which is not appropriate to disclose to you.”
- And my favorite: “Divulging the details of the factors that led to this decision can be exploited to construct targeted attacks to circumvent the security system”
A PDP can be configured to have access to back-end data that the client application is not trusted with. Returning this data with the decision would present a significant breach of security. The PDP defaults to returning only the authorization decision itself with no supporting data because this is the most secure option for all cases. A policy writer can opt to add Advice elements to rules to selectively disclose data to the PEP about the decision.
Granted, it is useful to have full disclosure of what’s going on inside the PDP when you are debugging a security policy that isn’t returning the authorization decisions you wanted. That’s outside the XACML spec and left as an exercise for the vendors. Because debugging the internal state of a PDP is inherently tied to the implementation details of the PDP, this isn’t a strong candidate for standardization because every implementation will be different.
When you put your PDP and policies into a production environment, you will turn off everything related to debugging.
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.
Wow. Another “Where did this come from?” A PDP should be a stateless service, which makes it ideal for scaling up to thousands of PDP nodes in the cloud to handle any amount of load. With every PDP instance running the same set of policies, so it doesn’t matter which PDP instance the PEP talks to: they’ll all give the same authorization decision for a given request.
If you’re looking at a PDP that cannot be hosted in the cloud or cannot be scaled up through replication because of some statefulness issue, you need to look for another PDP product.
When considering where to place a PDP service relative to an application, it helps to think of the PDP authorization service like storage. Would you implement a cloud hosted application that consumes data stored on your private corporate network? In most cases, probably not because the round-trip latency would drag your app responsiveness down. You’d locate your storage in the same data center that hosts your app so you have fast and easy access to the data – and no data bandwidth costs or quotas. In special cases where the data is too sensitive or too large to be uploaded to the cloud, taking the performance hit to remotely access the data residing on your private network may be more acceptable than the general case.
The same is true of other services your cloud-hosted application relies upon, including authorization. In most cases, it makes the most sense to locate one or more PDP servers in the same data center that hosts your app. The PDP servers may need to occasionally get policy updates from your corporate network, but these are relatively rare events and won’t affect service availability. The use case of having a cloud based app always calling into your corporate network for authorization would be extremely rare/unusual, requiring a mountain of extenuating circumstances to justify.
Commercial support is non-existent.
A curious statement considering the Forrester article opened with a mention of a commercial authorization product (Quest APS) which supports XACML and includes PEP libraries to facilitate application development. There’s no shortage of other commercial XACML PDP system vendors as well.
I suppose the fact that one of the largest network router makers uses XACML as part of their router security policy authoring system doesn’t count as commercial support for XACML. Or Boeing, or major banks and brokerage houses. I suppose the fact that the US Government (Defense Information Systems Agency JPES) requires XACML conformance in new systems doesn’t count as commercial support either. That’s the public sector, after all.
It’s true that you won’t find a PEP enabled shrink-wrapped software product in stores today. External authorization doesn’t provide much benefit for consumer applications installed at home (yet*). Large enterprises generally don’t send an intern out to pick up a 10,000 seat software product at OfficeMax. We shouldn’t judge the health of the business software industry by what you find on the shelf at the local office supply store.
(*)With the rapid acceleration of the rise of the machines the “Internet of Things” (tiny devices all through your house or office that communicate with each other over TCP/IP networks) authorization and access control in the home environment is going to become a big issue very soon.
Refactoring and rebuilding existing in-house applications is not an option.
It’s true. It’s hard to convert an application built long ago on the premise that it makes its own authorization decisions based on its own internal authorization policy logic into something that defers those decisions to an external authorization service, where policy can be changed rapidly without requiring a redeployment of applications.
You can avoid the cost of refactoring in-house applications by committing development resources to implementing corporate policy logic in each application in your organization, to updating each of those application every time corporate policy changes, and to deploying those updated applications in the field.
This will be much less expensive than refactoring for external authorization, so long as the number of applications you’re responsible for is less than 2, your corporate policy changes less than once annually, and/or all of your users reside in the same building.
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.
Apples vs oranges here. OAuth doesn’t provide fine-grain authorization. OAuth doesn’t provide external policy evaluation either. OAuth is a lighter weight response to things like SAML which can convey identity and user attributes in a secure manner. OAuth is a communication protocol to pass authorization data around securely. XACML is a policy evaluation system that produces authorization data.
You can use OAuth with XACML. You can use OAuth authorize a PEP to make requests to a PDP, or to convey user identity & attributes to the PDP as part of an authorization request. But since OAuth and XACML are fundamentally different things in the authorization stack, one cannot replace the other.
Yes, OAuth’s relative simplicity has enabled OAuth to trump SAML, particularly in the consumer web application space (Google, Facebook, Twitter, etc). That’s hardly a criticism of XACML. If constructing XACML authorization requests in XML is too difficult on your mobile device, then use the XACML REST and JSON profiles instead.
I hope you find these data points useful, and I look forward to Forrester learning more about XACML in the future. ;>
