I had the opportunity earlier in the week to attend the 9th Symposium on Identity and Trust on the Internet (IDtrust 2010) which was held at NIST.
Given that a lot of the work that I am currently doing is centered around externalized, policy driven Authorization using Attribute Based Access Control (ABAC) and the profiling and deployment of Enterprise Attribute Services, I found a paper (PDF) and presentation (PDF) given by Ivonne Thomas from the Hasso-Plattner-Institue for IT-Systems Engineering to be very interesting.
As an aside, one of the best explanations on conveying what ABAC is all about, particularly to business owners, was given by a colleague who works for the DOD in this particular domain (Thanks Ken B).
“Consider if you will, the following two situations.
You are standing in line at the Grocery store and a little old lady in a walker comes up to you and demands your driver’s license and proof-of-insurance! You will be making a particular decision at that time. Now, consider if the same question was asked of you with red and blue lights blinking behind you and someone with a badge and a gun is knocking on your windshield asking for the same information.
We make these types of decisions all the time in our lives based on a real time evaluation of who is asking the question, what they want access to, and the context in which the question is being asked. ABAC is how we could do the same thing in the electronic world. Making a real-time access control decision based on attributes of the subject, the attributes of the resource and the attributes of the environment/context.”
I love this explanation and have shamelessly stolen and used it to great effect in multiple situations.
Coming back to the paper, given that Attributes are used to make these critical access control decisions, how does one judge the “trust-worthiness” and/or “authoritative-ness” of each attribute that are used to make the decision? How could one convey these qualities related to attributes to a Relying Party so that it can make a nuanced access control decision?
On the authentication front, we have an existing body of work that can be leveraged such as the OMB E-Authentication Guidance M-04-04 which defines the four Levels of Assurance (LOA) for the US Federal Government and the attendant NIST SP 800-63 that defines the technologies that can be used to meet the requirements of M-04-04. In particular, you have the ability to use SAML Authentication Context to convey the LOA statements in conformance with an identity assurance framework.
The paper, which I think has a misleading title, uses the Authentication Context approach as an example and defines an extension to the SAML 2.0 schema for what is termed by the Authors as an “Attribute Context” which can be applied to each Attribute value. The authors define the parts as:
- Attribute Context This data element holds the attribute context, which is comprised of all additional information to the attribute value itself. This element is the upper container for all identity metadata.
- Attribute Data Source This data element indicates the source from which the attribute value was originally received and is part of the Attribute Context. This can be for example another identity provider, some authority as a certificate authority or the user himself who entered the data.
- Verification Context This data element holds the verification context, which comprises all information related to the verification of an identity attribute value. The Verification Context is one specific context within the Attribute Context.
- Verification Status This data element indicates the verification status of an identity attribute value, which should be one of “verified”, “not verified” or “unknown”. The verification status is part of the verification context.
- Verification Context Declaration The verification context declaration holds the verification process details. Such a detail could for example be the method that has been used for verifying the correctness of the attribute. Further extensions are possible and should be added here. The verification context declaration besides the verification status make up the verification context.
I know of many folks who are working on the policy side of this question of how to judge the “authoritative-ness” of an Attribute under multiple topics such as “Attribute Assurance”, “Attribute Practice Statements”, “Authority Services” etc. etc. But I have often thought about how one would go about conveying these types of assertions using current technology. This approach seems to provide an elegant approach for doing just that:
As you can see in the above example, the extensions proposed by the authors integrate nicely into a standard saml:AttributeStatement and convey the metadata about individual attributes to a Relying Party that can make a more nuanced access control decision.
I think this is a great beginning and would love to see the authors submit this to the OASIS Security Services (SAML) TC so that it can become part and parcel of the SAML 2.0 specification. I would also love to see a Profile come out of the OASIS SSTC that would define a consistent set of Verification Context Declarations. In particular I believe that the concept of referencing “Governing Agreements” as defined in the current “SAML 2.0 Identity Assurance Profile, Version 1.0”
(which is in public review) has applicability to this work as well.
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.