ADFS, WS-Federation and SAML in the enterprise

Another trend that seems to not be acknowledged by many identity bloggers is that enterprises are also interested in consolidating the number of identity stores within their walls and Active Directory makes a great place in which to accomplish such a thing. Your comment regarding diverse environments also equally applies to my own employer (Fortune 100). For example, would it be more honest if the community were to leverage existing technologies in some fashion vs SAML everywhere. One example may be that you could get IBM RACF to trust Active Directory via Kerberos vs making RACF understand SAML. I have no thoughts (at least ones I want to share publicly) on what architects in other enterprises think about. They are sure welcome to spend more money on acquiring products that should otherwise be integrated into existing enterprise products. Anyway, a balanced perspective is warranted over strictly rallying for SAML.

One additional thought. There seems to be missing thought as to the size of company in which one will want to federate with. For example, if a large mortgage bank such as Wells Fargo wanted to establish a federation, would it be with other large banks that could afford an expensive SAML infrastructure or would they want to federate with lots of small mortgage brokers who maybe have three people in the entire office and use what is built into AD out of the box?

Hi James,
Thanks again for the comments. I would never propose SAML as a ‘one size fits all’ solution - I see its principal utility in cross-domain web single sign-on. Some situations may well call for more tightly coupled approaches such as RACF-AD via Kerberos (being neither a RACF, AD or Kerberos expert I can’t comment on that example) but where enterprises (or even divisions of an enterprise) have autonomous identity management infrastructure, then SAML meets all of the requirements our customers have expressed, including vendor independence.
Moving on to your second comment, this is complex stuff in which the merits of the technology are a very small factor. We have seen that the contract issues of federation require much more time and energy than the technical implementation. A model that had a large financial institution such as Wells Fargo federating with many small mortgage brokers is technically straightforward, but, I believe, breaks when it comes to the legal and contract issues. The purpose of the federation would be to allow individual brokers to authenticate locally in their own environment, then single sign-on to the big FI. Each broker firm would have to satisfy big FI as to the security and compliance of their environment. I think, in this kind of model, big FI would prefer to keep control of the authentication process and have each broker manually log in.
A really good example of what does work is RouteOne, a web-based credit application management system developed by the finance arms of DaimlerChrysler, Ford, General Motors, and Toyota. RouteOne use SAML (in fact, Sun Java System Access Manager’s implementation of SAML) to enable single sign-on for auto dealers across the credit application systems of various auto manufacturers. Here, the individual user logs into RouteOne and is given access across a number of systems. The legal framework is much easier to manage since everyone is authenticating to RouteOne and they have relatively few relationships with the manufacturers.
At the end of the day, you pick the appropriate tool for the job. For example, for desktop-to-web single sign-on we implement SPNEGO, which is effectively Kerberos in a browser-friendly HTTP wrapper, since the vast majority of desktops are running Windows. ADFS’ built-in features may well enable simple federations where all parties are using MS technology (I really don’t mean that to sound patronizing - I just haven’t seen any evidence that it will be appropriate for large, complex deployments). SAML is a mature, technically capable, standardized, interoperable solution supported by the majority of identity management vendors and is proven in many deployments, large and small.

Curious why trackback has been disabled. Anyway, I responded in my blog…

Hi James,
AFAIK, trackbacks were disabled after the last spamstorm. I saw your blog entry - unfortunately, my day job has been getting in the way of blogging this week, and I go on vacation tomorrow. It might be January before I can write a proper response.

Quote: “[Microsoft] have chosen to do so using proprietary specifications (remember, WS-Federation is a specification, not a standard) …” WS-Federation and WS-* are not proprietary. Whether they’re a standard or not depends on who pays your salary.

Michael - that’s nonsense. As of this writing, not even a Microsoft employee would state that WS-Federation is a standard. Microsoft and other parties have proposed a technical committee at OASIS to standardize WS-Federation. If it was already a standard (and which organization, so far, has made it so?) what would be the point?