Supporting Multiple XACML Representations

We’re in the process of registering an XML media type for the eXtensible Access Control Markup Language (XACML). Simultaneously, the XACML Technical Committee is working on a JSON format.

Both media types are useful in the context of another committee effort, the REST profile. This post explains what benefit these profiles will bring once approved, and how to support them in clients and servers.

Media Types Support Content Negotiation

With the REST profile, any application can communicate with a Policy Decision Point (PDP) in a RESTful manner. The media types make it possible to communicate with such a PDP in a manner that is most convenient for the client, using a process called content negotiation.

For instance, a web application that is mainly implemented in JavaScript may prefer to use JSON for communication with the PDP, to avoid having to bring in infrastructure to deal with XML.

Content negotiation is not just a convenience feature, however. It also facilitates evolution.

A server with many clients that understand 2.0 may start also serving 3.0, for instance. The older clients stay functional using 2.0, whereas newer clients can communicate in 3.0 syntax with the same server.

This avoids having to upgrade all the clients at the same time as the server.

So how does a server that supports multiple versions and/or formats know which one to serve to a particular client? The answer is the Accept HTTP header. For instance, a client can send Accept: application/xacml+xml; version=2.0 to get an XACML 2.0 XML format, or Accept: application/xacml+json; version=3.0 to get an XACML 3.0 JSON answer.

The value for the Accept header is a list of media types that are acceptable to the client, in decreasing order of precedence. For instance, a new client could prefer 3.0, but still work with older servers that only support 2.0 by sending Accept: application/xacml+xml; version=3.0, application/xacml+xml; version=2.0.

Supporting Multiple Versions and Formats

So there is value for both servers and clients to support multiple versions and/or formats. Now how does one go about implementing this? The short answer is: using indirection.

The longer answer is to make an abstraction for the version/format combination. We’ll dub this abstraction a representation.

For instance, an XACML request is really not much more than a collection of categorized attributes, while a response is basically a collection of results.

Instead of working with, say, the XACML 3.0 XML form of a request, the client or server code should work with the abstract representation. For each version/format combination, you then add a parser and a builder.

The parser reads the concrete syntax and creates the abstract representation from it. Conversely, the builder takes the abstract representation and converts it to the desired concrete syntax.

In many cases, you can re-use parts of the parsers and builders between representations. For instance, all the XML formats of XACML have in common that they require XML parsing/serialization.

In a design like this, no code ever needs to be modified when a new version of the specification or a new serialization format comes out. All you have to do is add a parser and a builder, and all the other code can stay the way it is.

The only exception is when a new version introduces new capabilities and your code wants to use those. In that case, you probably must also change the abstract representation to accommodate the new functionality.

Advertisements

XACML In The Cloud

The eXtensible Access Control Markup Language (XACML) is the de facto standard for authorization.

The specification defines an architecture (see image on the right) that relates the different components that make up an XACML-based system.

This post explores a variation on the standard architecture that is better suitable for use in the cloud.

Authorization in the Cloud

In cloud computing, multiple tenants share the same resources that they reach over a network. The entry point into the cloud must, of course, be protected using a Policy Enforcement Point (PEP).

Since XACML implements Attribute-Based Access Control (ABAC), we can use an attribute to indicate the tenant, and use that attribute in our policies.

We could, for instance, use the following standard attribute, which is defined in the core XACML specification: urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier.

This identifier indicates the security domain of the subject. It identifies the administrator and policy that manages the name-space in which the subject id is administered.

Using this attribute, we can target policies to the right tenant.

Keeping Policies For Different Tenants Separate

We don’t want to mix policies for different tenants.

First of all, we don’t want a change in policy for one tenant to ever be able to affect a different tenant. Keeping those policies separate is one way to ensure that can never happen.

We can achieve the same goal by keeping all policies together and carefully writing top-level policy sets. But we are better off employing the security best practice of segmentation and keeping policies for different tenants separate in case there was a problem with those top-level policies or with the Policy Decision Point (PDP) evaluating them (defense in depth).

Multi-tenant XACML Architecture

We can use the composite pattern to implement a PDP that our cloud PEP can call.

This composite PDP will extract the tenant attribute from the request, and forward the request to a tenant-specific Context Handler/PDP/PIP/PAP system based on the value of the tenant attribute.

In the figure on the right, the composite PDP is called Multi-tenant PDP. It uses a component called Tenant-PDP Provider that is responsible for looking up the correct PDP based on the tenant attribute.

XACML Vendor: Axiomatics

This is the second in a series of posts where I interview XACML vendors. This time it’s Axiomatics’ turn. Their CTO Erik Rissanen is editor of the XACML 3.0 specification.

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

The world needs a standardized way to externalize authorization processing from the rest of the application logic – this is where the XACML standard comes in. Customers have different requirements for implementing externalized authorization and, therefore, can derive different benefits.

Here are some of the key benefits we have seen for customers:

  • The ability to share sensitive data with customers, partners and supply chain members
  • Implement fine grained authorization at every level of the application – presentation, application, middleware and data tiers
  • Deploy applications with clearly audit-able access control
  • Build and deploy applications and services faster than the competition
  • Move workloads more easily to the most efficient compute, storage or data capacity
  • Protect access to applications and resources regardless of where they are hosted
  • Implement access control consistently across all layers of an application as well as across application environments deployed on different platforms
  • Exploit dynamic access controls that are much more flexible than roles

What products do you have in the XACML space?

Axiomatics has three core products today:

  • The Axiomatics Policy Server which is a modular XACML-driven authorization server. It fully implements XACML 2.0 and XACML 3.0 and respects the XACML architecture.
  • The Axiomatics Policy Auditor which is a web-based product administrators and business users alike can use to analyze XACML policies to identify security gaps or create a list of entitlements. Generally, the auditor helps answer the question “How can an access be granted?”
  • The Axiomatics Reverse Query takes on a novel approach to authorization. Where one typically creates binary requests (Can Alice do this?) and the Axiomatics Policy Server would reply with a Yes or No, the Axiomatics Reverse Query helps invert the process to tackle the list question. We have noticed that our customers sometimes want to know the list of users that have access to an application or the list of resources a given user can access. This is what we call the list question or reverse querying.
    The Axiomatics Reverse Query is an SDK that requires integration with a given application. With this in mind, Axiomatics engineering have developed extra glue / integration layers to plug into target environments and products. For instance, Axiomatics will release shortly the Axiomatics Reverse Query for Oracle Virtual Private Database. Axiomatics also uses the SDK to drive authorization inside Windows Server 2012. And there are many more integration options we have yet to explore.

In addition, Axiomatics has now released a free tool and a new language called ALFA, the Axiomatics Language for Authorization. ALFA is a lightweight version of XACML with shorthand notations. It borrows much of its syntax from programming languages developers are most familiar with e.g. Java and C#. The tool is a free plugin for the Eclipse IDE which lets developers author ALFA using the usual Eclipse features such as syntax checking and auto-complete. The plugin eventually generates XACML 3.0 conformant policies on the fly from the ALFA the developers write. Axiomatics published a video on its YouTube channel showing how to use the tool.

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

Axiomatics fully supports XACML 2.0 and XACML 3.0 including all optional profiles as specified in our attestation email.

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

Axiomatics has historically been what we could call a pure play XACML vendor. This reflects our dedication to the standard and the fact that Axiomatics implements the XACML core and all profiles – no other vendor has adopted such a comprehensive strategy. Furthermore, Axiomatics only uses the XACML policy language, rather than attempting to convert between XACML and one or more proprietary, legacy policy language formats. The comprehensiveness of the XACML policy language gives customers the most flexibility – as well as interoperability – across a multitude of applications and usage scenarios.

This also made Axiomatics a very generic solution for all things fine-grained authorization. This means the Axiomatics solution can be applied to any type of application, in particular .NET or J2SE/J2EE applications but also increasingly COTS such as SharePoint and databases such as Oracle VPD.

Axiomatics also leverages the key benefits of the XACML architecture to provide a very modular set of products. This means our core engine can be plugged into a various set of frameworks extremely easily: the authorization engine can be embedded or exposed as a web service (SOAP, REST, Thrift…). It also means our products scale extremely well and allow for a single point of management with literally hundreds of decision points and as many enforcement points. This makes our product the fastest, most elegant approach to enterprise authorization.

Axiomatics’ auditing capablities are quite unique too: with the Policy Auditor, it is possible to know what could possibly happen, rather a simple audit of what did actually happen. This means it is easier than ever to produce reports that will keep auditors satisfied the enterprise is correctly protected.

Lastly, Axiomatics has over 6 years experience in the area and is always listening to its customers. As a result, new products have been designed to better address customer needs. One such example is our Axiomatics Reverse Query which reverses the authorization process to be able to tackle a new series of authorization requirements our customers in the financial sector had. Instead of getting yes/no answers, these customers wanted a list of resources a user can access (e.g. a list of bank accounts) or a list of employees who can view a given piece of information. By actively listening to our customers we are able to deliver new innovative products that best match their needs.

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

Axiomatics has several Fortune 50 customers. Some of the world’s largest banks and enterprises are Axiomatics customers. Axiomatics customers are based in the US and Europe mainly. One famous customer where Axiomatics is used intensively is PayPal. It is probably Axiomatics’ current biggest deployment in terms of transactions.

A US-based bank has also deployed Axiomatics products across three continents in order to protect trading applications.

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

Axiomatics supports Java and C#. Axiomatics has been used in customer deployments with other languages such as Python.

Axiomatics is active in defining the new REST profile of the XACML TC and will try to align with it as much as possible. Axiomatics is also leading the design of a JSON-based PEP-PDP interaction. JSON as well as Thrift are likely to be the next communication protocols supported.

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

Axiomatics does not currently support OpenAZ but has been watching the specification in order to eventually take part. Axiomatics already supports Spring Security. In addition, there is a new open source initiative aimed at defining a standard PEP API which Axiomatics and other vendors are taking part in.

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?

Should customers decide to write a custom PEP rather than use an off-the-shelf PEP, they can use a Java or C# SDK to quickly write PEPs. Axiomatics has published a video explaining how to write a PEP in 5 minutes and 20 lines of code.

An implementation of our product can take from 1 week to 3 months or more depending on the customer requirements, the complexity of the desired architecture, and the number of integration points.

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

The Axiomatics PDP can be embedded. Customers sometimes choose this approach to achieve even greater levels of performance.

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

There are many factors such as number of policies, complexity of policies, number of PIP look-ups and others that have an effect on performance. One of our customers shared the result of their internal product evaluation where they reached 30.000 requests per second.

The Axiomatics PDP is also used to secure transactions for several hundred million users and protect the medical records of all 9 million Swedish citizens.

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.