Archive

Posts Tagged ‘SPML’

a new SPML? a provisioning problem.

Mark Diodati of Gartner (that was a bit hard to type right the first time) has published the results of the SPML SIG held at #cat10. I think it captures the feeling of those present very well. At about the same time the minutes of the first meeting of the SPML PSTC for a long while were published. It seems there’s a much different split there than there was at the SIG. The split is basically between folks who want to see a “clean start” with a version 3 and those who want to see version 2 revved so it’s more realistic. I’m on the latter side, and so are the folks at Quest that I’ve spoken to. In fact, both and Quest and at customers, everyone I’ve spoken to about this outside a tight circle of “identity gurus” have all agreed that SPML would best serve the larger community as means to have systems communicate. Anything beyond that is overkill. At least for now. If all the different solutions had a standard way to do CRUD operations between one another, that would go a long way to solving many practical issues in heterogeneous IT environments.

I’d like to get more involved and I’m working with Quest to see if that can happen. This is something I’d like to see done from start to end.

BF8XDEVU8PDS This is here for Technorati. If you’re seeing it it’s because you’re reading this content somewhere besides my blog site and I couldn’t hide it from you. Sorry =]

SAML vs XACML for ABAC & AuthZ

March 9, 2010 2 comments

My esteemed fellow Quester Jackson Shaw just blogged about SAML being used for ABAC. I also heard a lot of talk about this at RSA last week in side conversations. I thought I may talk about it a bit; now Jackson’s given me the opportunity. It seems that using SAML to cure the ails of other less mature MLs is all the rage. I’ve also been watching Jeff Bohren‘s posts about SPML and SAML. In that case SPML is set against SAML + LDAP. I think it’s all related.

SAML is taking off. There are a lot of platforms and vendors supporting it, architects and developers are adopting it and it seems to have a mature set of features that are making all of them happy. But then you look to the next set of issues, provisioning (specifically just in time provisioning) and authorization, and you find much less satisfying results. So people have the old “if you have a hammer everything looks like a nail” short circuit and start asking why not use the thing everyone likes, SAML, for those problems, too? The saml.xml.org site gives a clear explanation of how SAML can be applied to ABAC:

SAML is being applied in a number of different ways, one of which is Attribute-based authorization. The attribute-based authorization model has one web site communicating identity information about a subject to another web site in support of some transaction. However, the identity information may be some characteristic of the subject (such as a person’s role in a B2B scenario) rather than, or in addition to, information about when and how the person was authenticated.

Like every hammer brought to bear on a screw, it falls short a bit. If all you need to do is pass attributes into the application, then SAML will help for sure. But if you’re looking for a way express and store policy about the content of those attributes and what the resultant set of decisions should be based on the expression of those policies, then you’re out of luck. That, and more, is precisely what XACML is; as wikipedia nicely states: “XACML … is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies.” To really solve the authorization problem, that’s what you need. And you especially need it if you want to solve the even larger issues around having common policy applied across many applications all sharing a common policy set, policy storage and management and policy delivery.

Of course, much of this may be semantics around the idea of ABAC. Ant Allen in his report “Adaptive Access Control Emerges” defines access control this way:

Access control traditionally combines two related, but distinct, functions:

  • Authentication – The real-time process of confirming a user’s claimed identity with a specified, or understood, level of confidence.
  • Authorization – The real-time process of deciding whether a user can interact with a particular resource in a particular way and enforcing that decision

Though I typically hear people discuss this as if authentication was one thing and access control is used as a synonym for authorization. If people use Ant’s definition, then SAML already handles all of the authentication part and can play in the authorization part as well by supplying attributes. But if access control is being used as a synonym for authorization, then SAML has less to offer since it only supplies the attributes and leaves the application to do the heavy lifting.

Under any definition of authorization, I think it’s safe to say that SAML will only be able to make a significant contribution after some heavy modification to include a lot of the XACML elements or through the emergence of some other cooperative standard that laps XACML and is very “SAML friendly”. Neither one of those is on any horizon I see. And any extension of SAML to be more XACMLish will only bring all the practical challenges that XACML adoption faces (application refactoring, policy definition, inter-application cooperation, etc.). And wouldn’t it defeat the purpose of using your nice hammer to make the handle 20 feet long and the head 50 pounds heavier?

%d bloggers like this: