Harvesting web technologies

Fine-grained access control using XACML in C# applications and the .Net framework

David Brossard — Wed, 01 Feb 2012 11:21:58 +0000

Background

When I talk to customers, I see an increase in interest in XACML for the .Net framework and the C# language. Historically, all XACML implementations have been in Java, most of them stemming from SunXACML. It is the case for instance of WSO2′s offering, SICSACML, and of course Axiomatics’ Policy Server.

Support for XACML in C#

Axiomatics and other companies have since released .Net PDPs and cover the space fairly well. In addition, it is possible to develop WS clients to SOAP-based PDPs regardless of the technology used.

A simple tutorial

The tutorial hereafter focuses on a C# example built using svcutil and the Axiomatics Policy Server’s SOAP-based PDP. With this code, it is therefore possible to invoke the Java-based SOAP-based web service from any .Net application.

Pre-requisites

Before you get started, you will need the .Net framework 3+ as well as the Axiomatics Policy Server. You can download them here:

.Net framework: download
Axiomatics Policy Server: request a download & evaluation license

Generating the .Net client stub

The .Net framework comes with a little utility called svcutil. This utility can generate client stubs from a WSDL such as the one that comes with the Axiomatics Policy Server. Using svcutil (or the add service reference… option in Visual Studio), let’s generate the client stub.

Use the Add Service Reference to generate a C# client stub for the Axiomatics Policy Decision Point.

This will bring up the following dialog where one can type in the path to a WSDL that describes any service for which one wants to create a client stub. In our case we can browse to our PDP service. In this example, the Axiomatics PDP is running locally inside an Apache Tomcat 7 web server. It is exposed as a SOAP web service.

The Add Service Reference… will scan the WSDL and display the available operations. We can inspect the different operations and eventually click on OK (after possibly changing the namespace for the newly generated client). Clicking on OK will lead to:

the generation of a C# file called Reference.cs which contains the client stub and serialization code.
the creation of a default configuration file, App.config, which contains the configuration for the endpoint such as the URL, the type of security and binding as well the message formatting. You can find more information on these files at Microsoft.

Use the Add Service Reference to browse to the PDP's WSDL and add a C# client stub.

We can now start writing a few lines of code to see how the client behaves. The code svcutil automatically generates is a direct mirror of the WSDL. This means the objects we can work with are objects defined in the WSDL. Let’s get started with a simple example. Let’s first create a standard C# class as below

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace com.axiomatics.sample.pep
{
    class PepC
    {
    }
}

What we now want to do is add a main method and an instance of the service reference we just added to our project. We can also call the GetVersion() method of the PDP which returns the product version (e.g. Axiomatics Policy Server 4.0.6).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ConsoleApplication1.DelegentPDPNoSec;

namespace com.axiomatics.sample.pep
{
    class PepC
    {
        static DelegentPDPPortTypeClient client = new DelegentPDPPortTypeClient();
        static void Main(String[] args)
        {
            client = new DelegentPDPPortTypeClient();
            GetVersion gv = new GetVersion();
            client.GetVersion(gv);
        }
    }
}

Let’s now focus on the actual authorization methods. The Axiomatics Policy Server includes a XACML 3.0 PDP which expects a XACML request and sends a XACML response back. The method we need to use to send a XACML request is InstanceAccessQuery3(…). We can simply add the line client.InstanceAccessQuery3();. However this method needs a parameter, namely the SOAP-wrapped XACML request. Let’s start from the beginning then and start creating a XACML request, bundle it inside the SOAP message and pass to our WCF SOAP client stub.

A XACML request is made of any number of attributes grouped into categories, typically the subject, resource, action, and environment categories. A request is simply the XACML representation of a plain old English question e.g. can Alice view the document? In this example:

Alice would be a subject identifier and belong to the subject category.
View would be an action identifier and belong to the action category
Document would be a resource type and belong to the resource category

An attribute in XACML is in fact made up of a bag of values (attributes can be multi-valued). Each value has a datatype (e.g. String, integer… Usually XML datatypes) and 1 or more values. Now, since attribute values can be any content as per the XACML 3.0 schema (see below), this means that svcutil generates classes that will require XML nodes to be built to set the value of an attribute. This is not particularly friendly and we will factor that away in a later part of this tutorial.

First off, let’s create the attribute that will represent the subject id Alice. We will start from creating a string that contains the value Alice. In a real scenario, this value would be read from an authentication mechanism.

            // 1. let's create a subject attribute
            String subjectId = "Alice";

We now want to store that value inside an AttributeValue. To do that we must use the objects generated automatically by svcutil.

            // 2. let's store the value inside an array of XmlNode[] preparing it for the SOAP call
            XmlDocument dom = new XmlDocument();
            XmlNode node = dom.CreateNode(XmlNodeType.Text, subjectId, null);
            XmlNode[] nodes = new XmlNode[1];
            // 3. let's store the XML any nodes inside an array of attribute values
            AttributeValueType1 aValue = new AttributeValueType1();
            aValue.Any = nodes;
            aValue.DataType = "http://www.w3.org/2001/XMLSchema#string";
            // we use an array below since attributes in XACML can be multi-valued
            AttributeValueType1[] values = new AttributeValueType1[] { aValue };

In the code above, note that we specify the data type of Alice. Most of the XACML datatypes are directly taken from XML itself. The list is defined in the XACML 3.0 specification. Also note we use an array of AttributeValueType1 since there can be several attribute values per attribute in XACML (the multi-valued nature of XACML attributes).

Let’s now wrap the values inside a XACML attribute (see the specification for details):

            // 4. create the containing attribute
            AttributeType1 attrContent = new AttributeType1();
            attrContent.Issuer = "some issuer"; // usually leave that blank
            attrContent.AttributeId = "subject-id";
            attrContent.AttributeValue = values;
            attrContent.IncludeInResult = true;
            AttributeType1[] attrContents = new AttributeType1[] { attrContent };

In the above code, note the use of IncludeInResult. This relates to the ability of a PDP to return the attributes initially sent in the request along with the decision. This is useful when using the Multiple Decision Profile. Also note that attributes can have an issuer. This is used in the matching process of the evaluation of a XACML request against a XACML policy.

Now that we have attributes and their values, in this case subject-id and Alice, we can group them (it) inside a given category. This is what the code hereafter does.

            // 5. create the category containing the attr and return
            AttributesType subjectAttr = new AttributesType();
            subjectAttr.Category = "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject";
            subjectAttr.Attribute = attrContents;
            // repeat the code above for any attribute e.g. actionAttr, resourceAttr...

Category identifiers are defined in the XACML 3.0 specification(section 10.2.6). In this case we use the subject category identifier, urn:oasis:names:tc:xacml:1.0:subject-category:access-subject.

We can now group together our different categories into an array of categories as below. We then build a XACML request from which we derive a SOAP request (merely the wrapping of the XACML request inside a SOAP message).

            // 6. bundle the attributes inside the set of attributes for the XACML request
            AttributesType[] attrs = new AttributesType[] { subjectAttr, actionAttr, resourceAttr };
            // 7. build the XACML request
            RequestType1 xacmlRequest = new RequestType1();
            xacmlRequest.Attributes = attrs;
            InstanceAccessQuery3 soapRequest = new InstanceAccessQuery3();
            soapRequest.InstanceId = "my-pdp-instance";
            soapRequest.Request = xacmlRequest;

The InstanceId attribute in the code above refers to which PDP instance the request should be sent to. The Axiomatics Policy Server PDP has a multi-tenancy model and the PDP instance id helps identify to which particular instance the XACML request should go.

Hands on the plumbing & Handling the response

In the following code, we simply pass the XACML request to the client stub method to invoke the PDP service. Notice how the answer received can contain multiple results, each of which boasts a single decision. This, again, is due to the Multiple Decision Profile which supports sending and receiving multiple XACML requests in a single network exchange (e.g. SOAP request/response).

            // 8. send the XACML request and print the response
            InstanceAccessQuery3Response response = client.InstanceAccessQuery3(soapRequest);
            foreach(ResultType1 result in response.Response){
                Console.WriteLine(result.Decision);
            }

Refactoring the generated code

The code to create a single XACML attribute is fairly lengthy and repetitive due to the automatic code generation done with svcutil. To get around that, let’s create a small utility method which creates the right type of attribute object from the simple building blocks of an attribute: its id, value, type, and issuer.

        public static AttributesType createAttribute(String id, Uri category, String value, Uri datatype, String issuer)
        {
            // 1. create the value
            AttributeValueType1 aValue = new AttributeValueType1();
            aValue.Any = createXMLBlob(value);
            aValue.DataType = datatype.ToString();
            AttributeValueType1[] values = new AttributeValueType1[]{aValue};
            // 2. create the containing attribute
            AttributeType1 attrContent = new AttributeType1();
            attrContent.Issuer = issuer;
            attrContent.AttributeId = id;
            attrContent.AttributeValue = values;
            attrContent.IncludeInResult = true;
            AttributeType1[] attrContents = new AttributeType1[] { attrContent };
            // 3. create the category containing the attr and return
            AttributesType attr = new AttributesType();
            attr.Category = category.ToString();
            attr.Attribute = attrContents;
            return attr;
        }

.
With this small utility in hand, we can rewrite our example in a more efficient way. Below, I have included an entire simple SamplePEP class which you can use with the Axiomatics PDP.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using com.axiomatics.xacml;
using System.Xml;
using ConsoleApplication1.DelegentPDPNoSec;

namespace com.axiomatics.sample.pep
{
    class SamplePEP
    {
        static DelegentPDPPortTypeClient client = new DelegentPDPPortTypeClient();
        private InstanceAccessQuery3 soapRequest;
        private RequestType1 xacmlRequest;
        static void Main2(string[] args)
        {

            SamplePEP pep = new SamplePEP();
            pep.callPDP();

        }

        public static XmlNode[] createXMLBlob(String content)
        {
            XmlDocument dom = new XmlDocument();
            XmlNode node = dom.CreateNode(XmlNodeType.Text, content, null);
            XmlNode[] nodes = new XmlNode[1];
            return nodes;
        }

        public static AttributesType createAttribute(String id, Uri category, String value, Uri datatype, String issuer)
        {
            // 1. create the value
            AttributeValueType1 aValue = new AttributeValueType1();
            aValue.Any = createXMLBlob(value);
            aValue.DataType = datatype.ToString();
            AttributeValueType1[] values = new AttributeValueType1[]{aValue};
            // 2. create the containing attribute
            AttributeType1 attrContent = new AttributeType1();
            attrContent.Issuer = issuer;
            attrContent.AttributeId = id;
            attrContent.AttributeValue = values;
            attrContent.IncludeInResult = true;
            AttributeType1[] attrContents = new AttributeType1[] { attrContent };
            // 3. create the category containing the attr and return
            AttributesType attr = new AttributesType();
            attr.Category = category.ToString();
            attr.Attribute = attrContents;
            return attr;
        }

        public void callPDP()
        {
            // 1. collect attributes
            Console.WriteLine("// 1. create attributes");
            AttributesType subjectAttr = createAttribute("subject-id", Constants.SUBJECT_CAT, "Alice", new Uri("http://www.w3.org/2001/XMLSchema#string"), "");
            AttributesType actionAttr = createAttribute("action-id", Constants.ACTION_CAT, "view", new Uri("http://www.w3.org/2001/XMLSchema#string"), "");
            AttributesType resourceAttr = createAttribute("resource-id", Constants.RESOURCE_CAT, "Document", new Uri("http://www.w3.org/2001/XMLSchema#string"), "");
            AttributesType[] attrs = new AttributesType[] { subjectAttr, actionAttr, resourceAttr };
            // 2. create XACML request
            Console.WriteLine("// 2. create XACML request");
            xacmlRequest = new RequestType1();
            xacmlRequest.Attributes = attrs;
            // 3. create wrapping SOAP request
            Console.WriteLine("// 3. create wrapping SOAP request");
            soapRequest = new InstanceAccessQuery3();
            soapRequest.InstanceId = "my-pdp-instance";
            soapRequest.Request = xacmlRequest;

            try
            {
                InstanceAccessQuery3Response resp = client.InstanceAccessQuery3(soapRequest);
                ResultType1[] results = resp.Response;
                foreach (ResultType1 res in results)
                {
                    DecisionType1 decision = res.Decision;
                    Console.WriteLine(decision.ToString());
                }
            }
            catch (Exception err)
            {
                Console.WriteLine(err.Message);
            }
        }
    }
}

Enjoy!

The distance of a second

David Brossard — Sun, 20 Nov 2011 12:09:59 +0000

One of my side hobbies is to browse the web for nice designs and interesting ways to represent information. I really like 2 blogs in particular: Information is Beautiful and the second is Grain Edit (check out their respective web stores for neat stuff).

In addition to liking design, I also truly like techy stuff and in particular programming languages or declarative languages (by that I mean Java in the former instance and XML in the latter). SVG is a great standard to draw vectorial images using XML.

I had therefore had my first attempt at representing information in a neat way: the distance of a second (the distance an animal / human / vehicle achieves in a fixed amount of time i.e. 1/60th of a minute). And the result is below…

Distance of a second

I used Inkscape to design the file. I used icons from the amazing Noun Project.

XACML 102: XPath and XACML

David Brossard — Thu, 25 Aug 2011 15:57:29 +0000

Some definitions

XPath: (see the W3C definition) query language for selecting nodes from an XML document. In addition, XPath may be used to compute values (e.g., strings, numbers, or Boolean values) from the content of an XML document. (source: wikipedia).
XACML: (see the OASIS definition) access control markup language defined to provided a standardized means to express fine-grained access control. XACML includes a reference architecture, a policy language, and a request / response protocol.

Uses of XPath in XACML

XPath is used in attribute selectors in XACML. Attribute selectors are defined in the specification in section 5.30. Attribute selectors contain XPath expressions that are run on the XML content that is sent within a XACML request.

XPath used in a single XACML request

In this use case, we want to use XPath in a policy / rule target or condition in order to use a value contained in the XML payload sent in the element of the XACML request (NB: there can be such an element in any of the attribute categories in the XACML request).
In the example here, we are sending an XML book record which contains a book title, publisher, and ISBN number. We want to be able to make an access control request based on the book title and the age of the reader. If the reader is less than 18 and if the title is equal to Gulliver’s travels, then the decision is a Permit.


  
http://www.w3.org/TR/1999/REC-xpath-19991116
  
    
      
        
          Gulliver's travels
          
        
        
          18

And the corresponding XACML request:


   
   
   
   
   
      
         Joe
      
      
         14
      
   
   
      
Gulliver's travels
xx-yy-zz
Axiomatics

XPath used in a multiple decision request

One of the key features of XACML is to be able to define profiles for specific uses (either best practices e.g. in export control or actual technical extensions such as the delegation profile). One such profile is the Multiple Decision Profile which explains how to create a single XACML request that will in fact represent multiple access control requests. The profile gives 4 ways of expressing such requests one of which makes use of XPath. Here is how:
Let’s assume the incoming XACML request is about reading books. There will be 2 attributes: the subject id, and the action ‘read’. The resource category’s XML content element will contain an XML element with multiple book children as follows:


   
      The Lord of the RingsJRR Tolkien
   
   
      Pride and PrejudiceJane Austen
   
   
      His Dark MaterialsPhilip Pullman

The XML document aforementioned lends itself well to a multiple question of the form “Can Joe read A? Can Joe read B? Can Joe read C?”. This is exactly the purpose of the use of XPath in the Multiple Decision Profile, but one has to be extremely careful in its use in order to avoid a few pitfalls.

In a follow-up, I will give sample policies and requests illustrating a correct use of the MDP.

Axiomatics seeks serious contender – impressions of Gartner Catalyst 2011 (#CAT11) 30,000 ft up.

David Brossard — Thu, 18 Aug 2011 12:22:59 +0000

I had the opportunity to fly with Axiomatics CEO, Babak Sadighi, on our trip back from San Diego to Stockholm. During the 15-hour journey, Babak and I shared our experience and impressions of the conference.

Gearing up to Catalyst 2011

The week of the 23rd of July turned out to be a pretty busy one at Axiomatics. As solutions architect, I flew over to San Diego for the much anticipated Catalyst Conference. I was keen on getting the dial tone in the Identity and Access Management space. Catalyst was to be the perfect place to catch up with Gartner analysts as well as colleagues from partner companies.
As a vendor of XACML solutions and pioneers of the XACML technology, my colleagues and I were keen on getting the opinions of analysts and end users to take those back home and enhance our offering.
In the 12 months since #CAT10, we have seen a surge in sales activities: an increased number of new leads, new contracts, and repeated interactions with prospect customers. Along with the increased frequency came more breadth. 2009 / 2010 was more about a handful of verticals. Today, requirements come from twice as many verticals from health and finance to media and manufacturing. And it brings us pride to see wider-spread adoption. Traffic on our website spiked; traffic on Gerry’s blog and mine also increased phenomenally.
And it’s not only customers: the company struck new partnerships with leading IAM system integrators such as First Point Global in APAC or Mycroft in the USA. New technical partnerships were announced with best-in-class vendors such as Radiant Logic (virtual directories).
We saw this intense activity as a sign of market readiness. As such, we had very high expectations in San Diego. We were eager to learn about customer experiences – your experiences – as well as competitors’ experiences and lastly analysts’ views on the coming twelve months.

New use cases, new opportunities

In a sense, our expectations were exceeded: XACML was all over the conference (at least in the identity track). Bob Blakley and his team repeatedly mentioned the technology, its now proven maturity, the use cases, and the existing vendors such as ourselves but also promising open source alternatives such as WS02 or PicketBox.
One end-user organization, Fidelity, came to talk about their deployment using XACML and how they meet with regulatory compliance. (more details on the track here)
In a separate track, Ian Glazer talked about the importance of high-quality data for IAM (How IAM Depends On Hi-Fi Data… And Doesn’t Know It Yet). This is what we call making smart decisions with trustworthy attributes.
Axiomatics was also in the headlines as its CEO signed a new partnership agreement with IDMWorks to strengthen the brand’s presence in the cloud.
And speaking of cloud, Axiomatics partnered with Radiant Logic to implement a cloud-based demonstrator using the Axiomatics Policy Server combined with RadiantOne VDS Context Edition to deliver fine-grained access control on a sales application.
In another instance, Axiomatics partnered with Layer 7 Tech to deliver fast, secure, and context-aware SOA security for any type of applications again hosted inside an Amazon instance.
It really felt like we were on par and that 2011 was year 1 of widespread XACML adoption. There was even a lunch session entirely dedicated to XACML.
This leads me to conclude that to those skeptics, XACML is now a reality.

Where’s the competition?

In a thriving market, one would expect a wide range of competitors to react and strengthen their offering; to act responsibly and deliver better products. In that sense, we were a bit led down. It’s a well-known fact that the driving forces behind the XACML standard are IBM, Oracle, and Axiomatics. I would like to stress that Axiomatics in particular has fueled the efforts in the last 6 years with its CTO, Erik Rissanen, taking the editorial responsibility for XACML 3.0. But the larger organizations, as often, are now lagging behind a handful of smaller, faster players such as Axiomatics.
In fact there was a single other small vendor at Catalyst 2011 with a XACML offering but they have yet to take part in the innovation effort.
For instance, we would love to see more industry engagement in the XACML technical committee. It’s not just about engagement. It’s also about endorsement: the reason XACML 3.0 has not become a standard is because it has not been attested by 3 different vendors and/or end-users. Axiomatics has attested to the latest implementation of the standard and several other profiles. We are still waiting for other vendors to follow suit. It would do the standard good if more enterprise-ready implementations stood up to the challenge.

Axiomatics involvement in the XACML TC: CTO Erik Rissanen is the 2nd most prolific contributor.

If you want to know more about contributions, the history of the XACML TC, and the current work, check out the TC mailing list and the XACML dev list.

Fact or fiction?

When I look at the offering in the security space, my head almost always ends up spinning. There are many different vendors to choose from (quite a few were at Catalyst) and they offer many different standards-based solutions. Some of my customers struggle to understand the difference between authentication and authorization. The messaging we give out is of critical importance and we should make sure we state verifiable facts.
In the XACML space, many vendors claim some level of implementation. How complete is their implementation? Others claim to be the fastest. Are they really? Have they compared? I wrote a post on this very topic pointing readers to areas that need serious investigation. Caution is the key word here.
This is where we would need a serious report from the analyst community – a health check if you like – on the state of fine-grained access control today. A magic quadrant perhaps?

Outlook

We are pretty excited at Axiomatics about the future. New customers are knocking on our doors and our teams are expanding (sales; engineering; drop me a line if you are keen on joining us). Yet we want to make sure that the one standard we believe in, the reference for fine-grained access control doesn’t get tarnished by false marketing claims. We want the competition to rise to the challenge of XACML 3.0. We can only grow through a healthy debate between vendors that offer comparable products. And we want you, the customer, to reap the benefits.

The world’s fastest XACML engine

David Brossard — Mon, 18 Jul 2011 15:08:46 +0000

In the last few months, I have been reading statements from a wide variety of vendors / open-source XACML implementations that they have the world’s fastest 100% XACML standards-based engine.

This reminds me of heated debates that involved national pride and engineering feats when the French and Japanese were head-to-head in designing the world’s fastest trains. And the Chinese have since then caught up. The Wikipedia article is a trove of trivia when it comes to speed and how records were achieved (or what they actually mean). In the table summary, I can spot quite a few ‘current world record’ labels… If by the time you finish reading the article, your head is not spinning one way or the other, then you’re ready to take on the ‘fatest XACML engine’ claim.

So who’s the fastest? How can one claim to be the fastest? After all what does it mean? Don’t you need to compare to other engines? To date, only one such comparison has been done by academics on open-source engines [1].

In pure absolute terms, the fastest engine is the one that can process the most XACML access control requests in a given time, usually brought down to a second for comparison purposes. The statement however should raise a few questions:

Are these live access control requests?
The requests being sent are live requests. There is no caching involved (no decision caching, no attribute caching). The PDP engine is processing each and every request and is returning a decision.
Are the requests actually using XACML?
The request should be XACML-conformant. Sadly, not many implementations out there claim to conform with the XACML 2.0 standard or XACML 3.0 specification. Check that the solution you go for does. If a solution manages high levels of access control requests by cutting corners or not respecting the standard, the solution will fall apart when scaling or when evolving towards new, more demanding scenarios.
How are the requests being transported?
The form factor of the request: in a performance test or benchmark used to create those figures, any form factor can be used. If one uses XACML expressed in its XML form inside a SAML assertion inside a SOAP message, I would bank the figures would rate poorly. SOAP’s middle name is not ‘Speedy Gonzales‘. Typically, a performance test would therefore be achieved using XACML’s representation in code (Java, C, C#, depending again on the implementation. SunXACML uses Java).
Do the requests & policies used in benchmarks accurately represent business complexity?
The request and the policies should be meaningful and represent a varying level of complexity. When you are presented with a benchmark, ask to see how the results were computed and real-world complexity was simulated. A fellow vendor likes to use his kids in examples. I don’t have any so I’ll use my niece as an example – she can splutter out ‘no’ so fast that I’d reckon she might well be the fastest decision engine in the world. True, she’s not XACML-conformant and besides she’s got a deny-all policy. That’s not very useful. So remember, ask how complex a request is and how large the policy set being evaluated is.
What is the architecture being used?
Performance can be impacted or enhanced depending on several architectural considerations: how many engines are used? How are engines combined together? Can engines scale horizontally? Vertically?
Do performance figures represent real production data?
Have they simply been estimated in a lab environment? In the end, performance needs to be proven in real-time and in real-world use case scenarios. What actual experience and evidence from production systems have you been given?

It’s easy to claim one is the fastest. But one should tread carefully and check the face value of any such statement. Ask to understand how performance levels are achieved. Ask how such performance levels can be sustained and made resilient to different attacks or simply highly volatile levels of traffic.

The good news is XACML provides a very clean and decoupled architecture that makes it easy to address these concerns. It’s just a matter to make sure whether the solution you go for does respect the XACML architecture. As an architect at Axiomatics, I’m proud to say we do. And that’s business sense. Respecting the standard is a first stepping stone to a future-proof solution but it is not enough: performance is critical. Our products reach extremely high levels of performance through years of research & innovation – and we prove this on a daily basis in the world’s largest deployments – be it in terms of users, services, data, or simply throughput.

PS: don’t forget to come visit us at Gartner in San Diego later this month where we will illustrate fine-grained access control in the cloud with best-of-breed vendors Radiant Logic (attribute virtualization) and Layer 7 (SOA security – see their flyer here: http://www.layer7tech.com/beachparty/).

[1] Fatih Turkmen and Bruno Crispo. 2008. Performance evaluation of XACML PDP implementations. In Proceedings of the 2008 ACM workshop on Secure web services (SWS ’08). ACM, New York, NY, USA, 37-44. DOI=10.1145/1456492.1456499 http://doi.acm.org/10.1145/1456492.1456499

Coarse-grained vs. fine-grained access control – part I

David Brossard — Sat, 28 May 2011 21:46:40 +0000

A few weeks ago, Baljinder Wadhwa, a consultant at HP, started an interesting thread on coarse-grained vs. fine-grained access control trying to figure out what the differences were between the two. His question generated a high level of great answers that went in different directions. This post aims at summarizing those answers, bringing in my own view, and producing a structured answer to Baljinder’s question. Here goes…

Vocabulary definition

Coarse: (1) composed of relatively large parts or particles (2) : loose or rough in texture
Fine: (1) very thin in gauge or texture (2) : not coarse (3) : very small (4) : keen (5) : very precise or accurate

Definitions from the Merriam-Webster
The definitions start to hint at what the differences might be: fine-grained access control will work on smaller items whereas coarse-grained access control will work on larger items.
Granularity can apply to the message being intercepted or the information being considered for access control. Ultimately, the rules being define will allow for more or less granular AC. Examples:

Coarse: Employees can open the door.
Fine: Employees based in the US can open or close the door during office hours.
Finer: Employees in the Engineering department and based in the US can open or close the door during office hours if they are assigned to an active project.

A little history of access control

In application security, there are grossly speaking 3 types of access control:

Access control lists (ACL): with access control lists, once a user is authenticated, that user is allowed to access an application or not depending on whether that user’s id is on a list of authorized users (white list) or blocked users (black list). This mode is either all-in or all-out. It is extremely coarse-grained from that perspective. It is also coarse-grained in the sense that it only considers one dimension, that of the user, ignoring resources, actions, and context. However, it is extremely fine-grained in the sense that it becomes a user-specific rule. In the previous examples, John is the user id that would be on the ACL for the open door action.
Role-based access control (RBAC): sometimes, though, it is not who you are but rather what role(s) you embody. For instance, a person might be allowed to open a door. That right (or permission) is granted because that person has the role employee, not because of who they are. Typically, in RBAC, a user can have multiple roles to which different permissions can be granted. Take wordpress for instance, the popular blogging platform. WordPress lets users define roles and associate permissions to roles and then roles to users therefore transitively granting users permissions. But roles have their limits too. How do you express other conditions or parameters? What if you want to express a permission of the following form: “only employees can open the door between 9AM and 5PM”. With RBAC, you can express employee + open door. But you cannot really express the time constraint. In addition, what if you want employees who can only close doors? You would need to define employee_open and a employee_close role. This leads to role explosion.
Attribute-based access control(ABAC): to address this, one needs to be more discriminate, finer in terms of what information is considered to define a rule. Instead of defining permissions based on roles only, one should be able to use attributes. Attributes are any bit of data, or label, that describes a user, resource, target, object, environment, or action. Anything from an apple, its color, and weight to a person eating that apple, the location of the apple… With ABAC, you can mix and match attributes to define extremely targeted (fine-grained) rules e.g. employees can open the door between 9AM and 10AM or close the door after 5PM if and only if the employee belongs to the ‘door opener’ group.

Standards for access control

In the previous paragraph, we looked at some broadly used and accepted access control models: ACL, RBAC, and ABAC (yes, access control is for acronym lovers). Let’s check out standards that back these models.

ANSI INCITS 359-2009 RBAC Role-Based Access Control: this standard defines role-based access control and its model.
XACML: this OASIS-driven standard defines a policy language, request/response protocol, and architecture that implement ABAC.

The NIST has a webpage dedicated to RBAC which summarizes extremely well the different RBAC standards existing and their variations / applicability.

In addition to the ANSI RBAC and the OASIS XACML standards, there are standards for ACL but these tend to be OS-specific.

Of all the standards out there, XACML is the one providing the finest granularity.

Defining access control granularity

The granularity of an access control framework can be defined from two different angles:

the expressiveness of the grammar used to express access control rules:the more flexible a grammar and the more information it can cater for, the finer grained the resulting access control will be. XACML can consider attributes about users, resources, actions, and the environment. This makes it very fine-grained. RBAC implementations typically focus on the user role and the target application therefore losing a bit of granularity since it won’t be able to make access control decisions based on actions, other subject attributes, or the context.
the ability of the ‘agents’ to see more or less information: in order to make fine-grained access control decisions, there is a need for agents or interceptors to be able to inspect business messages flowing through them. If, for instance, an agent can only see the URI of an HTTP message and the user principal name, then it can (most likely) only make decisions based on that. On the other hand, if the agent is capable of inspecting the entire message, including all HTTP headers plus the payload of the message, then more fine-grained AC requests can be generated. This is why there are firewalls which typically look at TCP packets, XML gateways which look at SOAP/REST messages, and many other types of gateways / interceptors in between. Interceptors can be business app-specific e.g. interceptors for Sharepoint or SAP which enable fine-grained access control.

In a second instalment, I will focus on the issues of scale around granularity of access control. I will also list some product categories and vendors that address different levels of granularity. Stay tuned!

Gluecon 2011 – day 1 – Axiomatics Interview: fine-grained access control for your APIs using XACML

David Brossard — Thu, 26 May 2011 14:47:16 +0000

Gluecon 2011 – Impressions of Day 1 – Waste Management Through Security Automation

David Brossard — Thu, 26 May 2011 12:51:43 +0000

Gluecon started off with an amazing video / presentation on a mind-nubbingly large screen. It felt like the Oscars of IT. After the usual round of intros led by Eric Norlin, we moved on to the core of the topic: APIs and all their applications today including, of course, within cloud.
Chris Hoff of Cisco started with an analogy with toiletry / plumbing over the centuries pointing out that in the last 10 years, we had seen radical innovation in toilets, a millenium-old technology. Apply that to software dev and cloud, and we should see some serious innovation coming our way. (Side note: the indispensable toilet paper was not invented until quite a few centuries after toilets were. It makes you ponder what they were using before).
Chris’s talk focused on security mainly. He pointed out to a model where he clearly separates concerns between different layers:

Infostructure: info security applies here
Applistructure: application security applies here
Metastructure
Infrastructure: physical & network security

The importance of pointing out to these different layers is that it highlights the different security concerns and the different stakeholders. In order for cloud and next-generation IT to function properly, all stakeholders must act together in a coordinated fashion.
It is very true: all too often, we will see a secure system being taken down because of one under-estimated area or because of those boundaries between 2 different secure layers: this goes back to what Theo Dimitrakos, head of Security Architectures at BT, used to repeat to me: the juxtaposition / interconnection of 2 secure systems rarely leads to one global secure system. Attackers will always try to attack the border where the two systems are joined.
And Chris to conclude in his talk that what we really need is:

Kick-aas automated security

(aas = as a service).
This goes through automated / standardized means of communication between different layers and through collaboration between different stakeholders: dev + ops + security = make nice to put it in Chris’s own formula.

XACML 3.0 wins award at the European Identity Conference 2011 #EIC11

David Brossard — Wed, 11 May 2011 17:42:58 +0000

Today was a great day at EIC 2011 where Axiomatics is currently demoing its fine-grained authorization capabilities based on the latest version of the XACML standard, XACML 3.0.
It ended with the usual ceremony awards where Tim Cole et al. handed out awards to various projects in the identity space (cloud security, IAM, entitlements management).
A special award was handed to the XACML Technical Committee for its outstanding work on the latest version of XACML, XACML 3.0. Hal Lockart of Oracle and co-chair of the TC stepped up to accept the award and thanked the entire TC for a great group effort. He also thanked the editor of the XACML 3.0 specification, Erik Rissanen, CTO Axiomatics, for leading the effort and major contributions.
XACML 3.0 brings many new things to the table among which advice, variables inside obligations, and perhaps close to Erik’s heart, delegation. More on new features of XACML 3.0 here.
The XACML TC will be hosting a free webinar on XACML in early June. Details can be found here.

Hereafter the video of the award ceremony and Hal going on stage:

When OpenID meets XACML: externalize authentication and authorization from your business apps

David Brossard — Mon, 02 May 2011 17:23:40 +0000

Background

About a year ago, a few months into my new job at Axiomatics, I pulled together a web-based app using J2EE (JSF, servlets, POJOs) and Icefaces (AJAXfied JSF) to illustrate fine-grained access control for web applications and portals.
To secure the application, I used Tomcat’s authentication mechanism (its implementation of the HTTP FORM-based authentication protocol) and Axiomatics‘s off-the-shelf Authorization filter for servlets.
What I then got – at zero development effort – was a sturdy, secure, finely-grained controlled web app where users could access certain pages and/or parts of pages based on the set of attributes a given user had potentially combined with attributes of the targeted resource (the page, the portlet, the individual GUI element of the page…), the action the user wanted to run (HTTP GET? HTTP POST?), and possibly environment values (time, encryption type?). We were pretty much cruising down XACML Lane, picking all the benefits of Attribute-Based Access Control.

Out goes FORM-based AuthN, in comes Open ID

However, I was not really satisfied with the authentication side of things. I had gone for the easy path – to use Tomcat’s native tool (a list of users inside a configuration file called tomcat-users.xml) which I had extended to include other user attributes. But it didn’t seem overly realistic in an enterprise scenario. I had thought of using LDAP but had never found the time to configure Tomcat to use LDAP instead.
That’s when I bumped into Travis Spencer of Ping Identity. A few weeks ago, Travis came over for a visit in our Stockholm offices. Then and there, Travis introduced me to Ping’s capabilities in terms of (a) externalizing authentication and (2) bridging between different authentication sources and protocols. I wasn’t restricted to Tomcat’s FORM-based authentication anymore. I could choose from a plethora of identity providers, typically OpenID-based providers such as Google or Yahoo, but also Facebook Connect.
The source of authentication and the ease of integration are not the only winning factors here. Considering XACML – in the authorization phase – uses attributes extensively, one of the key points is to be able to retrieve such attributes. And that’s where OpenID, SAML, and Ping come into play. It is indeed possible to authenticate with an IDP and retrieve attributes about the user the IDP might be maintaining.

The best of both worlds: achieving externalized authentication & authorization

With that in mind, Travis and I drew up a plan for a new demo integrating Ping Identity’s Ping Federate and Axiomatics’s Policy Server. Travis also describes the architecture on his blog.
In addition to inserting the Axiomatics Servlet Authorization Filter, I now added an Authentication filter responsible for redirecting users to the authentication form of their favorite IDP e.g. Google via Ping Federate. From my app’s perspective, and in particular the filter’s perspective, that amounted to an HTTP 302 redirect to Ping Federate which in turn redirected to the relevant IDP. What’s interesting to note is that PF might talk different protocols with different providers but ultimately always returns the same pre-agreed token format to the authentication filter. In our case, we opted for an encrypted cookie which contained additional attributes about the user.
The authentication filter can then decrypt the token, extract the attributes, create a user session, and add those attributes to the session. Next comes the Authorization filter which can read those attributes from the session and use them to build a XACML request to be sent to the APS. It can also add contextual attributes such as the time of the request. Lastly, it is capable of extracting additional information from the HTTPServletRequest object itself, typically the targeted URI and the HTTP method (GET? POST?)
Based on the attributes it is given, the APS can then reach different decisions (either Permit or Deny). In this demonstrator, we opted for a resource-centric access control model where we defined different policies grouped together in a policy set. Each policy focuses on a separate resource (or web page as is the case here). Policies can contain rules which can focus on finer-grained aspects of the resource e.g. a GUI element (a button? a menu item?). Lastly, because multiple sources of authentication are potentially used, it is possible for APS to reach decisions based on the origin of the user token. Administrators can then author access control policies of the like:

Only allow users that have authenticated with Google.

Richer business flows with XACML obligations

One of the neat features XACML offers is the use of obligations. Obligations are statements that a PDP can return to a PEP along with a decision e.g.

Yes Permit, provided the PEP logs the fact the user has requested this resource in the corporate logging system.

In this demo, obligations are particularly handy. We chose to implement a banking scenario where certain pages require different levels of authentication (from none to OpenID to internal enterprise authentication). Should a user authenticated with Google try to access a page which requires stronger authentication, the PDP can deny access and ask the PEP to redirect the user to a page where the user will have the option to either log in using an enterprise account or create a new account.
This sort of scenario is recurrent with our banking customers: imagine a retail bank webapp where users authenticate using their normal credentials (e.g. username/password). The bank lets them view their balance. However, for more advanced functions e.g. money transfers, the bank requires stronger authentication. XACML obligations can implement this type of flow very naturally.

A sneak peek at the demo

This short video demo illustrates the use of Ping Federate with Google OpenID and Axiomatics Policy Server.