There is a strong consensus in the security community that Attributes, in particular Attributes that apply to users or other entities participating in requests which are subject to access control, are a key source of information for making access control decisions. These are usually called Subject Attributes. Some people go so far as to talk about Attribute-based Access Control (ABAC) although this typically includes other types of Attributes such as Resource Attributes and Environment Attributes as well.
Microsoft has popularized the concept of Claims-based access control. However, the precise meaning of Claim is not entirely clear.
WS-Trust and WS-SecureConversation contain the following definition.
Claim – A claim is a statement made about a client, service or other resource (e.g. name, identity, key, group, privilege, capability, etc.).
Web Services Security and WS-Federation contain the following definition.
Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, attribute, etc).
Identity Metasystem Interoperability (Information Card) contains this.
Claim – A “Claim” is a piece of information about a Subject that an Identity Provider asserts about that Subject.
During a presentation given at the 2009 Kerberos Conference Kim Cameron said flatly “Claims are Subject Attributes.”
I think at a minimum we can conclude that Claims include Subject Attributes, and thus there is general agreement that distributing and validating Subject Attributes issued by trusted authorities and consumed by relying parties is an important component of access control.
However, all this agreement masks the issue of what sort of information Attributes should contain about the Subject and whether the sort of information chosen has implications for the operation of the access control system. The most familiar type of information contained in Subject Attributes pertains to the Subject, independent of any particular access request. Examples include: job title, project name, security clearance level, citizenship and telephone number. I call Attributes of this type Properties.
Alternatively, Attributes can contain information about what the Subject is allowed to do. For example the attribute might indicate that the Subject is allowed to read a particular file or to create an appointment in the calendar for a particular day. In the academic security literature these types of Attributes are called Capabilities.
Let us imagine that a user wants to read a file on Server X called “ProjectPlan” which is associated with Project Y. We will further assume that generally users are allowed to read files that are associated with the projects of which they are members. To allow this we might issue an Attribute that has any one of the following meanings:
- Is allowed to read file “Project-Y/ProjectPlan” on “Server-X”
- Is allowed to read any file in the “Project-Y/” directory on “Server-X”
- Is allowed to read any file belonging to “Project-Y”
- Is a member of “Project-Y”
Number 1 has the advantage that it makes it easy for the file server to figure out what to do. On the other hand, it only covers that exact request. A similar Capability will be required for each request. If the overhead of requesting and processing them is significant it could impact latency.
Number 2 fixes this by allowing access to all the files in the directory. But now a new issue surfaces. What if IT operations decides to refactor the directory structure so the file is now called “Projects/Project-Y/ProjectPlan”? Or perhaps they introduce a new server naming convention so the server is no longer called “Server-X”. Not only will the previously issued Attribute no longer work, but the issuer will somehow have to find out about the changes made to the infrastructure and change what it issues accordingly.
Number 3 has a similar effect to number 2, but uses a metadata tag instead the name of the directory. Of course there may be practical difficulties with storing and obtaining the tag, but assuming that the information is available, the user will be allowed to access the desired files, even if their location changes or if they are distributed over multiple directories or servers. On the other hand, the file server will have to do a bit more work to determine that a given access should be allowed.
Number 4 crosses over to a pure Property-type of Attribute. Although the file server will have to evaluate a policy (or ask a friendly PDP to do it) the policy may be quite simple and general, e.g. “Any Subject may read any files which are associated with projects the user is a member of.” On the plus side, the Attribute value is now completely independent of the access request being made. There is no need for any kind of coordination between the trusted authority and the file server. Further, this Attribute may be used as an input to an entirely different access control decision which does not involve files at all.
From this we can see that Properties and Capabilities are not absolute alternatives, but rather form a range of possibilities which represent tradeoffs in flexibility, performance, clarity of expression and ease of management. I call this the Property-Capability Spectrum. I think that these tradeoffs exist in a variety of access control architectures. It turns out that somebody at Microsoft noticed this tradeoff a while ago, but of course they don’t use the same terminology as I do.
In my next post I will more directly compare the operation of an infrastructure which uses a Capability-oriented approach with a more familiar one.
