Analyzing Identity

The latest hyperbolic headline from our friends in the analyst community is brought to you by Andras Cser of Forrester, who proclaims that XACML is dead. Naturally, we at Axiomatics disagree since we have invested many years of effort at OASIS to develop and support the standard. The timing of this post is also interesting in that XACML version 3.0 was just formally ratified earlier this year and the Technical Committee is actively working on new profiles to support a REST interface as well as JSON encoding of the request/response formats – two features that will significantly expand the appeal to a wider developer audience. Let’s walk through this and address some of the statements that Andras makes:

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

I am not sure what you mean here Andras as XACML already does access control.

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.

While XACML has not hit the mass market, we continue to see increased adoption across many industries. Organizations that have written their own authorization engines are investigating commercial alternatives, due to the cost of maintaining home grown systems and keeping up with growing requirements.

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.

This is not correct on multiple levels. First, XACML was designed to meet the needs of service oriented architectures – which are, by definition, not monolithic in architecture or deployment patterns.

Second, the XACML standard never mandated that all users be managed centrally in AD or any other repository. Some products may have this limitation, but it is a vendor choice to do so. In fact, the policy information point is specifically defined to retrieve attributes or meta data from heterogeneous, distributed sources.

Finally, the XACML architecture naturally supports federated environments because access decision making and policy enforcement can be deployed centrally or in a distributed approach to cater for performance and other operational preferences. In fact, one of the simplest ways to achieve a hybrid IAM strategy for the cloud is to leave AD in the corporate enterprise and use authorization to communicate access control decisions.

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.

Actually, you can optionally communicate context about the decision using Advice or Obligation statements – part of the XACML standard. In version 3, these statements can contain variables and are very useful for communicating additional information to the PEP. Some examples are to redirect the user to a stronger authentication page, tell the user they have an insufficient approval limit, or tell the user they are not assigned to the patient so they can’t see the health record.

Keep in mind, many situations specifically require that the PEP not know why the access failed, because it could leak information for an attacker. Firewalls and network access control solutions are examples of this.

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.

The modular architecture of XACML is absolutely suitable for cloud and other kinds of distributed deployment scenarios. The fact that major components such as the PEP, PDP and policy authoring are decoupled means you can deploy them in many configurations. Embedding the PDP with the PEP and application is one option, but you can also co-locate the PDP with the app for better performance. As with on-premise deployments, implementers have to consider the latency between PEP to PDP and attribute retrieval. Cloud scenarios may present some challenges in reference data synchronization or retrieval, but many options are available to address them. 

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.

I acknowledge that, as an industry, we have not adequately addressed the ISV industry with sufficient tooling to externalize authorization. As a result, we continue to see the creation of ‘new legacy’ applications that are difficult to manage and operate from an IAM perspective. Axiomatics has recently joined and contributed to the OpenAz project in an effort to meet these requirements.

Regarding SharePoint, we agree that a PEP-to-PDP model is difficult to implement for this platform, which is why we have taken a different approach.

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…)

Another point of agreement: Most existing applications will not be rewritten to implement an externalized authorization approach. However, there are ways to integrate with existing applications without changing the application’s code by using filters or proxies, for example.

Additionally, many organizations are exposing existing applications by building API or web services layers – this is the perfect integration point for incorporating externalized access control.

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.

OAuth and XACML are not mutually exclusive, but certainly have their respective strengths/weaknesses. Again, I will point to the REST and JSON profiles for XACML that are currently under development at OASIS – these profiles will make XACML-based systems more easily integrated with mobile and other light weight platforms.

This entry was posted on May 8, 2013 at 1:15 pm and is filed under Authorization, Standards, XACML. You can subscribe via RSS 2.0 feed to this post's comments. You can comment below, or link to this permanent URL from your own site.