Archive

Posts Tagged ‘ldap’

SAML vs LDAP to the death?

April 8, 2010 3 comments

…with tag team partners STS for SAML and the VDS (Virtual Directory Server) for LDAP?

So I’ve taken Jackson‘s advice and have been reading Microsoft’s “Guide to Claims-Based Identity and Access Control”. While most of it has been things I’ve heard before, the formulation of the ideas the way Microsoft wants to present them to their favorite audience, developers, is very interesting.

The thing that caught my eye and inspired a whole lot of conversation, lightbulbs for me and this post was a quote very early on:

“ADFS has a rule engine that makes it easy to extract LDAP attributes from the user’s record in Active Directory and its cousin, Lightweight Directory Services. ADFS also allows you to add rules that include arbitrary SQL statements so that you can extract user data out of your own custom SQL database. You can extend ADFS to add other stores. This is useful because, in many companies, a user’s identity is often fragmented. ADFS hides this fragmentation. Your claims-based applications won’t break if you decide to move data around between stores.” (from page 6)

Described like this, the STS sounds a heck of a lot like a VDS. So I asked many of the Quest big brains what they thought of the quote and what the quote made me think. I was quickly told that this was silly since the models for an STS and VDS are so different. Some of their points were:

  • STS is a push model where users show up at the applications with claims ready and VDS is a pull model where the application needs to go get the information
  • The VDS approach is about applications using data from multiple sources without modifying the application while the ADFS + WIF approach is about teaching the application to consume claims natively by modifying it
  • The STS and SAML approaches wraps the claims, the identity data, into the authentication operation while the VDS approach simply exposes a service for the application to use through the applications operations.

Somewhere in the midst of this discussion, a big gear clicked into place. I saw something I bet many, many have seen before – but it was new to me. Microsoft and Oracle were really going head to head in identity for applications. Yes, I know it’s hard to believe that Microsoft and Oracle would compete. But that does seem to be what’s happening. You see, the VDS had always been in this spot on my mental whiteboard between the applications and the multiple sources of identity data as an abstraction layer. The STS was somewhere on that mental whiteboard, but it wasn’t there. Now I’d been clearly shown that it could be moved in front of the VDS, or even be moved to replace the VDS. Of course, much depends on the use cases. The STS can’t really do everything the VDS does and vice versa. But I think it’s fair to say that Oracle is betting on people like me who see with an application architect’s eye and try to make the current generation of revenue generating applications do their work better and faster. Microsoft is betting on it’s excellent developer community and credibility to propel the next generation of all applications into a claims based, STS dependent world.

That battle would seem to pit SAML and LDAP against each other, each with one of the largest tech giants in it’s corner. In reality, I doubt it will be anything so dramatic. But before this conversation, I didn’t even see the potential for that battle. It’s amazing how many latent hostilities to some approaches seem clear to me now. I don’t even think some of the people who were hostile realized why. But there are deep mechanisms at work in the respective communities involved that are forming opinions that will likely solidify into “Linux vs Windows Server” style opinion wars soon enough. Here I thought all this good will about interoperability in identity could last forever. Silly me.

Advertisements

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?

stuck in the middle with you

last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.

everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.

wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…

Categories: iam Tags: , , , ,
%d bloggers like this: