XACML Vendor: eNitiatives

This is a new series of posts where I interview XACML vendors. The first one that was kind enough to participate was eNitiatives.

Why does the world need XACML? What benefits do your customers realize?

Our primary customers are in Government, Defense, Intelligence, Telecommunications, and Health, with some key multinationals. All of these customers are concerned about providing fine grained authorizations for controlled access to digital assets. In the Defense, Government, and Intelligence sectors this is especially critical.

What products do you have in the XACML space?

We have two current products where we have implemented XACML, and one upcoming:

  1. Firstly we have ViewDS. This is our LDAPv3, X.500 and ACP 133(D) Directory server. Here we have built a PEP into our Directory server and use XACML to provide Policy Based Access Control to all data that we store within our Directory. Our Directory includes an Indexing and Search engine supporting 24 different types of searching and matching and fully supports XPath queries and can understand XML content.

    ViewDS has a Management Agent used to control and manage content in our Directory Server. In our latest release, it now has an inbuilt Policy Administration Point tool. ViewDS also has an inbuilt Policy Decision Point. ViewDS thus acts as both an Identity Store and a Policy Information Point as policies can be stored in the Directory schema and are treated as Directory Attributes. As well as XACMLv3, ViewDS fully supports RBAC, Label Based Access Control and Time Based Access Control

  2. Our Second Product is known as ViewDS Access Sentinel. Access Sentinel is an XACMLv3 Policy Decision Point designed to be used for externalizing authorization policy for external applications. Access Sentinel provides a combined PDP, PIP, two PAPs and a number of PEPs off the shelf. ViewDS Access Sentinel can use either ViewDS as its identity store, or an external LDAP Directory or Virtual Directory as its LDAP Identity Store.

    ViewDS also supports multiple schemas and with its inbuilt join engine, ViewDS Access Sentinel plus ViewDS Discovery server offers the capability to also join other data from external services. We have a number of PEPs available and will be announcing some new ones in our v7.3 release. We also offer a second PAP tool for providing fully delegated policy creation

  3. Also in our next release (ViewDS v7.3) we will be launching a third product: ViewDS Identity Bridge. ViewDS Identity Bridge is a bidirectional synchronization and provisioning engine. This will also support XACMLv3

ViewDS and ViewDS Access Sentinel are available for Oracle Solaris 11g, two versions of GNU/Linux and Windows Server 2008 and Windows 7. Other implementations on versions of UNIX are available.

What versions of the spec do you support? What optional parts? What profiles?

In ViewDS version 7.2 (the current release) we support the core specification minus XPath, the Administration and Delegation Profile, the Hierarchical Resource Profile, the Multiple Decision Profile, the Privacy Profile, the Intellectual Property Control Profile and the Export Compliance-US Profile.

An internal build of ViewDS Access Sentinel already supports XPath version 1.0, and we have now built support for XPath in our two XACML PAPs. This capability will be in the next release due out in September. The next release will also support the administration and delegation profile and the multiple decision profile. We are also looking at an implementation of the Export ITAR Profile for a specific US Customer. We are also considering the GeoXACML extensions.

What sets your product(s) apart from the competition?

Unlike other vendors we do not require an external database license such as SQL Server or Oracle to store policies or require an external server. Our PDP, PIP, Attribute Identity Store and PAP are all in the one platform.

This means our product performs well, as all activities are internal function calls. That is, there is no external processing. Because we treat XACML policies as standard directory attributes (ViewDS itself fully supports XML), we can use standard directory protocols to distribute policies which are kept fully in sync with the associated identity attributes. Our Policy Administration Point tools also allow the creation of policies without the need to write any XML and support a capability known as Named Expressions.

What customers use your product(s)? What is your biggest deployment?

All of our ViewDS customers worldwide (our product is in use in Defense, Intelligence, Government, Aviation, Health and multinational corporations with installations in 16 countries) that upgrade to ViewDS v7.2 released in March will have the full capability of XACMLv3 in this release. Roughly 30% of our customers have upgraded already. Our largest implementation covers 26M identities, but our product has been tested with up to hundreds of millions of entries.

ViewDS Access Sentinel was released 3 months ago as a stand-alone product. So far we have a small number of installations in Australia and North America in the Government and Defense sectors.

What programming languages do you support? Will you support the upcoming REST and JSON profiles?

For PEP development, in our V7.2 release we currently support C#/.NET. We now have a PEP library for Java complete but not yet released. This will be provided to customers for the v7.3 release due in September.

Our current plan is to support both the REST Profile and the JSON Profile. However, the REST draft is not publicly available, has not been listed in the working group’s deliverables and hasn’t even been accepted by the working group yet according to the draft itself. This Working Draft (WD) has been produced by one or more TC Members; but we understand has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft).

Do you support OpenAz? Spring Security? Other open source efforts?

We are currently involved with other XACML vendors (BitKoo/Quest/Dell and Axiomatics) led by Felix Gaethgens from Axiomatics in an open source effort that is getting underway to create a PEP API and implementation for XACML version 3.0 among other things. We are not involved in any other open source effort.

However, we partner with Ping Identity for integration of Authentication and Authorization.

How easy is it to write a PEP for your product(s)? And a PIP? How long does an implementation of your product(s) usually take?

We provide a C#/.NET library known as PDP Liaison and now have a Java equivalent available to allow application vendors to create PEPs in a matter of days. We are currently considering making these Open Source solutions.

We expect a customer to be live in test mode and creating policies in 3 days depending on whether they are using ViewDS as the Identity Store or an external Identity store such as Active Directory.

Can your product(s) be embedded (i.e. run in-process)?

The PDP runs in a separate process.

What optimizations have you made? Can you share performance numbers?

Performance will vary depending on the number and nature of the policies, but version 7.2 has been clocked at 3650 XACML authorization requests per second with a single quad-core Intel Xeon E5430 CPU at 2.66 Ghz.

XACML Supports All Major Access Control Models

In a previous post, I talked about one of the most advanced access control models to date: Risk-Adaptive Access Control. In this post, I will put this in context by taking a closer look at a variety of access control models.

Access Control Defined


Access control is all about permitting or denying access requests. An access request occurs when:
a given subject tries to access
a given resource to perform
a given action in
a given environment.

The NIST Survey of Access Control Models

The National Institute of Standards and Technology (NIST) issued a report that identifies the following access control models:

  • Access Control Lists (ACLs) (subject, resource, action, N/A)
    The subject is either a user or a group. In some cases it can be an application.
    ACLs are hard to maintain when many users share privileges. For example, all developers should have access to the source code management (SCM) system. If the SCM is upgraded with a new feature that has its own permission, then the ACLs for all developers must be updated.
    ACLs are widely available, for instance in operating systems.
  • Role-Based Access Control (RBAC) (role, resource, action, N/A)
    Users are now generalized into roles, like developer.
    Roles are often not granular enough. For example, only the developers for product X should have access to the product X SCM. This can be fixed by introducing finer-grained roles, but that often leads to an explosion of roles. Sometimes there are even more roles than users in a system!
    RBAC is commonly available, for instance in relational databases.
  • Attribute-Based Access Control (ABAC) (subject, resource, action, environment)
    Everything is now generalized into attributes. Environment attributes, like the current time, are now also supported.
    Attributes are often used differently in different applications. For instance, one application may name the attribute for role role, while another may use role-id. Or one application may use an ID into a role table as the value of the role attribute, while another uses the role’s human readable name.
    ABAC is considered state of the art.
  • Policy-Based Access Control (PBAC) (subject, resource, action, environment)
    Attributes are now harmonized across all applications of the (extended) organization. For instance, the Core and Hierarchical Role Based Access Control (RBAC) Profile for XACML defines the URN urn:oasis:names:tc:xacml:2.0:subject:role for the role attribute.
    We’re just starting to see some PBAC implementations.
  • Risk-Adaptive Access Control (RAdAC) (subject, resource, action, environment)
    The environment attributes now take on a much more important role. In particular, dynamic risk levels are encoded as attributes.
    I know of no implementations of RAdAC, but I think we’ll start seeing them soon(ish), since they can help in the fight against Advanced Persistent Threats.

Trends in Access Control Model Evolution

If you look closely at this mostly chronological development of access control models, you’ll find the following trends:

  1. Access control becomes more fine-grained
  2. Access control becomes more policy-based, less ad-hoc
  3. Access control becomes external to applications

XACML Supports All Major Access Control Models

The eXtensible Access Control Markup Language (XACML) is an OASIS standard for ABAC. Since ABAC is a generalization of RBAC, and RBAC is a generalization of ACLs, it’s not surprising that XACML can handle all of those access control models. Furthermore, PBAC is technically just ABAC. The PDP doesn’t care what attributes are used, or how they are named. Nor does it care whether does attributes represent dynamic risk levels, as in RAdAC.

So the conclusion is that XACML supports all the major access control models. This makes XACML a future-proof technology. It will easily accompany you on your journey to a more sophisticated access control model.

LinkedIn Incident Shows Need for SecaaS

Security is a negative feature.

What I mean by that is that you will never get kudos for implementing a secure system, but you certainly will get a lot of flak for an insecure system, as the recent LinkedIn incident shows. Therefore, security is a distraction for most developers; they’d rather focus on their core business of implementing features.

Where have we heard that before?

Cloud Computing to the Rescue: SecaaS

Cloud computing promises to free businesses from having to buy, install, and maintain their own software and hardware, so they can focus on their core business.

We can apply this idea to security as well. The Cloud Security Alliance (CSA) calls this Security as a Service, or SecaaS.

For instance, instead of learning how to store passwords securely, we could just use an authentication service and not store passwords ourselves at all.

The alternative of using libraries, while infinitely better than rolling our own, is less attractive than the utility model. We’d still have to update the libraries ourselves. Also, with libraries, we depend on a language level API, which segments the market, making it less efficient.

There are some hurdles to tackle before SecaaS will go mainstream. Let’s take a look at one issue close to my heart.

Security as a Service Requires Standards

The utility model of cloud computing requires standards. This is also true for SecaaS.

Each type of security service should have one or at most a few standards, to level the playing field for vendors and to allow for easy switching between offerings of different vendors.

For authorization, I think we already have such a standard: XACML.

We also need a more general standard that applies to all security services, so that we have a simple programming model for integrating different security services into our applications. I believe that standard should be REST.
Update: The market seems to agree with this. Just see the figures in this presentation.

This is one of the reasons why we’re working on a REST profile for XACML. Stay tuned for more information on that.

So what do you think about SecaaS? Let me know in the comments.

Risk-Adaptive Access Control with XACML

Risk-Adaptive Access Control (RAdAC) is an advanced access control model where access decisions depend on dynamic risk assessments. In this post, I’ll show how RAdAC can be used in the fight against Advanced Persistent Threats (APTs).

Before I make that point, let me start off with a simple illustration of RAdAC in action. Then I’ll show how to implement RAdAC using eXtensible Access Control Markup Language (XACML).

Risk-Adaptive Access Control Demo

I’ve built a simple demo around RAdAC, which Jeroen van Rotterdam showed at EMC World 2012. Here’s how it works.

In the default situation, the threat level is at green, and the user is able to see and edit a document:

Green

However, when the threat level goes to yellow, the user is no longer able to edit the document:
Yellow

Finally, when the threat level goes to red, the user can’t even see the document anymore:
Red

Using XACML to Implement Risk-Adaptive Access Control

The demo may be simplistic, but it is a fully working system based on XACML. And, not unimportant from a software development perspective, it was very easy to build.

Remember the XACML architecture:

Given this architecture, all we need (from a technical perspective) to support RAdAC is a Policy Information Point (PIP) that looks up the dynamic risk attributes (environment oval in the above diagram). Once we have that, these attributes can be used in access control policies like any other attribute (subject-id, role, resource-id, action-id, etc, etc.)

In the demo, the threat level is set by clicking the traffic light. In the real world, a PIP would be connected to an Intrusion Detection System so that it can calculate the value of the threat level attribute.

The nice thing with an access control architecture based on XACML, is that no software needs to be updated to support RAdAC. All we need is to hook up the Policy Decision Point (PDP) to a PIP that calculates the threat level. You could go finer-grained as well, and split the one threat level attribute into several, if that’s what your access control policies require. How you write your policies has no impact on your applications, since the PDP and PIP can be re-used across all applications in your organization.

Risk-Adaptive Access Control and the Fight Against Advanced Persistent Threats

I think it won’t be long before we’ll start seeing implementations of RAdAC, since it can be a big help in the struggle against APTs.

With RAdAC, we make decisions up front about what to do in the event of an intrusion, and formalize those decisions in automated access control policies. Then when a security incident occurs, we can focus our energy on getting the intruder off the system instead of on protecting our information assets, since that will already have been taken care of.

What do you think? Is your organization interested in solutions like these in the fight against APTs? Please share your thoughts in the comments.

State of XACML

A while ago I wrote that the eXtensible Access Control Markup Language (XACML) may be on the verge of a breakthrough. Let’s see how that prediction holds up in light of recent events.

XACML as a Standard

The OASIS Technical Committee that defines the XACML specification recently voted version 3.0 to Committee Draft Specification. A public review will follow and then the spec will move to Committee Specification and from there to Standard.

To become an OASIS standard, there must be at least three attestations of successful use of a specification. We recently got the third attestation from the Bank of America, so things are looking good on the standardization front.

XACML in the Market

But how is the market responding? I don’t have a good overview of global XACML adoption. I did, however, recently attend an XACML seminar in the Netherlands, which gave me a good impression of XACML adoption in the low countries.

The seminar kicked off with a couple of general presentations. The main point of mine was that XACML is a future-proof technology for authorization, since it can handle all major access control models. Then we moved on to talk about actual implementations.

Martijn Kaag talked about the use of XACML in eRecognition (eHerkenning), which provides authentication and authorization services for businesses and government agencies. It is required for all Dutch national, regional and local government agencies.

Oscar Koeroo talked about the use of XACML in the academic grid computing world. This is a spectacular infrastructure for particle physics research. Talking about Big Data! They make heavy use of XACML obligations.

Maarten Wegdam talked about an XACML pilot at a large Dutch bank, where they relied a lot on context information, mostly having to do with location. This context is stored in XACML environment attributes.

Conclusion

Things are definitely moving in the right direction, but XACML still seems confined to some isolated cases. It may take some time before we see widespread use. Until that time, we can learn from a couple of interesting places where people are pioneering with XACML.

XACML going mainstream?

At the recent RSA conference, five organizations participated in an interop for the eXtensible Access Control Markup Language (XACML), based on version 3.0 of the XACML core spec and the Intellectual Property Control profile that is currently being defined. The interop was a big success, but its significance goes beyond the conference. So far, two organizations have formally attested conformance to XACML 3.0, but the interop featured five parties. This makes it likely that a third attestation is very close, and only three attestations are required before a specification can become an official OASIS standard.

There are other signals as well that XACML is doing well. Many people and organizations seem interested enough that they want to start experimenting with it, and many more are seriously contemplating that.

And that makes sense to me (although I’m obviously biased). One reason is the impact that cloud computing is making, since XACML is perfect for use in the cloud. And adoption in cloud scenarios will become even easier with the REST and media types profiles that are currently being defined.

All in all, I have a feeling that a breakthrough is in the air.

If you’re interested in XACML yourself, and you live in or close by the Netherlands, then there is a good opportunity for you to learn more about how XACML is used in practice at the upcoming seminar in Utrecht on April 26. The program for this full day event is almost finalized and ranges from the abstract (how does XACML fit in a security architecture) to the very concrete (experience reports from real implementations) and everything in between, like a demonstration from XACML vendor Axiomatics. Two members of the XACML Technical Committee will be there, so seize this opportunity to ask all and any questions you may have! The presentations will be in English, but most presenters also speak Dutch. Follow this seminar on Twitter via #xacmlnl.

So, what do you think? Do you see more implementations around you? Do you have a feeling that you need to know more about this important access control standard? Let me know in the comments.

A REST API for XACML

The wonderful book RESTful Web Services describes a procedure for developing RESTful web services. In this post, we will apply this procedure to XACML.

The eXtensible Access Control Markup Language (XACML) describes an architecture for authorization. The components of the architecture that are of interest to us here are the Policy Decision Point (PDP) and Policy Administration Point (PAP). The PDP is the component that decides on an authorization request. The PAP is the component that maintains the authorization policies that the PDP uses to reach its decision. There are more components in the architecture, but from a web services standpoint, the PAP and PDP give a client everything it needs to write and evaluate authorization policies.

Resources
Key to the REST architectural style is to identify resources and name them with URIs. The book states that “A resource is anything interesting enough to be the target of a hypertext link.” There are three different types of resources:

  • Predefined one-off resources for especially important aspects of the application
  • Resources for every object in the data set the service exposes
  • Resources representing the results of algorithms applied to the data set

An example of a predefined one-off resource is the list of XACML policies. We name that resource with the URI /policies. Note that this is a relative URI, the actual URI will be something like http://www.example.com/application/policies. In this post we will show relative URIs only.

An application can have many policies, which means the response could become very large. We solve that problem using pagination: we will return a small number of results only. If a client wants more results, it can use query parameters to do so: /policies?offset=100&count=20.

Resources from the data set that our service exposes are the individual XACML policies. We name policies with the URI /policies/{policyId}, where the part between {} is variable. We could even go a step further and include finer-grained resources like rules, attributes, and conditions. Their URIs would be /policies/{policyId}/{ruleId}, etc.

An example of a resource that is the result of an algorithm is the PDP’s access decision, which we arrive at by matching the policies with the request attributes. This resource is a bit trickier to name, since we need to supply input to it, which is usually accomplished using query parameters. So we could name this resource with the URI /decision?attribute1=value1&attribute2=value2&... A XACML attribute is identified by multiple pieces of information: category, id, and data type. We could encode these in a query parameter name using the scheme {category}/{id};{dataType}. Here we follow the convention that / implies hierarchy, while ; implies unordered combination.

However, with categories like urn:oasis:names:tc:xacml:1.0:subject-category:access-subject, ids like urn:oasis:names:tc:xacml:1.0:subject:subject-id, and data types like urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name, the URI will grow very big very quickly. There is no theoretical limit to URI length, but many applications will enforce limits in practice. (There is even an HTTP status code for this situation.) So we will need a way to shorten the URI considerably.

One way to do that, is to define shortcuts for standard attributes. For instance, instead of writing urn:oasis:names:tc:xacml:1.0:subject-category:access-subject/urn:oasis:names:tc:xacml:1.0:subject:subject-id,urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name, we could just use subject. To avoid conflicts, these shortcuts would have to be standardized along with the REST API.

The other potential problem with this approach is that / and ; are valid parts of URIs, and therefore could be used in categories, ids, and data types. The chances of this happening are not very high, though. The XACML specification uses : to separate components, and extensions would be wise to follow that example. Otherwise, they could use percent encoding.

Uniform Interface
The next step is to determine what operations are allowed on what resources. In a RESTful architecture, operations use the HTTP verbs only. This is called the uniform interface. We must identify the HTTP verbs supported for each URI, and also determine what HTTP status codes they return.

The list of policies, /policies, only supports GET, to retrieve the policies. There is no need to support POST to create policies: policies are named by ID, and the ID is part of the content, so it must be known to the client. This method will always return 200 OK if the server is operating fine. Otherwise, a 500 Internal Server Error will be returned. This last status is returned for all methods on all resources when there is a problem with the server, so we will not mention it any further.

PUT on /policies/{policyId} creates a new policy, or overwrites an existing policy. GET retrieves a policy and DELETE removes it. GET will return either 200 OK or 404 Not Found. PUT and DELETE will normally return 204 No Content. PUT can additionally return 415 Unsupported Media Type when the representation in the request (see below) is not understood.

The /decision resource, being algorithmic, only supports GET. Possible return codes are 200 OK, or 400 Bad Request when a parameter is invalid. This could happen when an unknown category, id, or data type is specified, or when the value supplied doesn’t match the data type. It can also happen when an unknown shortcut is used to identify a variable.

Like all web services, a XACML PAP needs to be secured. Whatever means used for that is out of scope for this discussion, but there are some additional status codes that the web service may return, irrespective of the security means. 401 Unauthorized means that the user making the request didn’t provide sufficient credentials, while 403 Forbidden means that the user doesn’t have the privileges required to honor the request.

Representations
The next step is to design the representations of the resources. There are two such representations: those presented to the server by the client, and those returned to the client by the server.

Clients don’t always have to provide content to the web services. Only PUT on /policies/{policyId}/ requires input, namely the policy. The representation of a policy should simply follow the XML format that the XACML standard prescribes. There is no media type registered for XACML at IANA, so we’ll have to make do with text/xml.

The representations returned by the server are a bit trickier. First there is the list of policies returned by /policies. This service could either return all the policies in XACML format, or only the IDs. Chances are this service is invoked to determine which policies exist. It’s not clear that their details are always required, so it may make more sense to just return the IDs, since that keeps the response leaner. Atom is always a good representation for lists of entries with links, but XACML 3.0 has a construct named PolicyIdentifierList that specifically represents a list of policy IDs. We should use that instead of Atom, since it’s extremely likely that the client can already parse XACML, but not that they can also parse Atom.

In order for representations to drive the state, which is the point in REST, they should contain links to other resources. So /policies should return not just IDs, but also links to the policies identified by those IDs. PolicyIdentifierList doesn’t provide for that, however. But we can augment it using the standard way of linking in XML: XLink. An example would be:

<PolicyIdentifierList xmlns:xlink='http://www.w3.org/1999/xlink
    xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <PolicyIdReference xlink:href="/policies/urn:sample:policy:id">urn:sample:policy:id</PolicyIdReference>
</PolicyIdentifierList>

The result of GET on /policies/{policyId} should simply be the XACML policy in the canonical XML format. The issue of linking comes up here as well, so we’ll use XLink again. For instance, a policy set can contain a PolicyIdReference.

The result of /decision is a XACML decision, i.e. one of Permit, Deny, NotApplicable or Indeterminate. We should represent that with the XACML Decision XML element, since the client can likely already parse that.

So this is my proposal for a REST API for XACML. What do you think?

Update: There is now an official REST Profile for XACML.

XACML at XML Amsterdam 2011

Less than three weeks till XML Amsterdam 2011 where I’ll be speaking on XACML.

XML Amsterdam is a small, focused conference dedicated to XML. As part of X-Hive EMC’s XML R&D center, I live and breathe XML, so I’m glad to have an XML conference in the Netherlands. The conference is small, so we won’t get lost in the crowd and the chances of good networking opportunities are high. And it is completely focused on XML, unlike Momentum, for instance. Finally, with speakers from all major native XML databases (xDB, MarkLogic, and eXists), we can expect some lively discussions 😉 . Especially with EMC IIG Chief Architect Jeroen van Rotterdam opening the conference with a keynote titled Is XML dead?

My presentation will introduce eXtensible Access Control Markup Language (XACML), an XML language for access control. I will place XACML in the context of access control models, and show that XACML is a future-proof technology that organizations can start using now, and then stay with as their access control needs evolve. I will continue to explain the architecture, request/response protocol, and policy language that make up XACML.

Here are my slides.

CQRS by Example – XACML

Often, when people talk about dividing a software system up into layers, they mention that you should start with the domain model. Note the word the, suggesting there is only ever a single domain model.

Not so with Command-Query Responsibility Separation (CQRS, see also CQRS Clarified). This is a pattern where the domain is described by more than one model. Updating of information happens by executing commands on one (or more) models. Viewing of information happens by querying one (or more) other models. The command and query models obviously need to be synchronized.

To see the value in such a separation, let’s consider an example. The eXtensible Access Control Markup Language (XACML) defines an XML language for expressing access control policies, and an architecture for evaluating access requests. The architecture defines different components that play different roles. The most important for the current example are the Policy Administration Point (PAP) that maintains access control policies, and the Policy Decision Point (PDP) that evaluates access requests.

Both the PAP and the PDP work with the same access control policies, but their relationship with these policies is quite different. The PAP should be able to edit and import policies, and must, therefore, understand the canonical XML format of XACML. The PDP, however, should respond as quickly as possible and XML may not be the best format to achieve that. By letting the PDP (query) work with a different model than the PAP (command), an XACML imlementation can perform best on both fronts.

XACML 3.0 is now Committee Specification Draft

Good news! Version 3.0 of the eXtensible Access Control Markup Language (XACML) has just been voted a Committee Specification Draft. There will only be a 15 day public review, since it has already been at that level before we dropped back to Working Draft. There is still a long way to go until version 3.0 becomes an OASIS standard, but at least we’ve started down that path.

What is XACML?
In short, XACML offers an architecture for access control, a policy language for describing and evaluating access control policies, and a protocol for requesting access. I’ve written about XACML in a series on EMC’s Developers Network:

What’s new in 3.0?
Axiomatics were the first company to implement 3.0 (their CTO, Erik Rissanen, is editor of the spec). They’ve also summarized what has changed since 2.0, the current OASIS standard:

Who’s using XACML?
Obviously not many people are using 3.0, since it’s not a standard yet. But 2.0 has been around since 2005 and is used in various places. Below is a sample of places where XACML is being used:

I’ll update this list when I find more examples. If you know of any, please let me know.

Update 2011-08-19: BitKOO is the second vendor to attest 3.0 compliance, after Axiomatics.