ADFS, WS-Federation and SAML in the enterprise

2 minute read

James McGovern left an interesting comment on my previous entry concerning WS-Federation and SAML 2.0.

James says

A customers perspective is slightly different than what you suggest in your posting. MS is doing the right things with WS-Federation. After all, if you consider that 99.9% of all Fortune enterprises and their B2B partners have AD installed, they would eliminate not only the need for SAML but for enterprises to buy yet another piece of software that really should be bundled with the OS in order to solve for problems across enterprises. Federated identity conversation is somewhat consumer focused. Would be great if participants could put on an enterprise lens when considering solutions….

Thanks for the comment, James. I think you’re right, up to a point. Microsoft is doing the right things, from the perspective of MS themselves and ‘MS shops’. If you have a pure MS infrastructure, then WS-Federation and ADFS are great news. If you have a mixed environment, and some or all of your business partners have a mixed environment, then this is good news, but it could have been so much better. After all, if MS had issues with the way SAML worked in their environment, they could have contributed to the SAML 2.0 process in OASIS and we would have had the ‘grand convergence’ of federation specs. But, for their own reasons, they chose not to engage there.

I spent Monday with one of our biggest enterprise customers. They have selected SAML 2.0 for web single sign-on across their various departments and divisions and with external partners. WS-Federation makes no sense for them as they have no MS SSO infrastructure - it’s all Sun, IBM and Oracle (Oblix). In common with the 99.9% of Fortune enterprises you mention, they do have AD as a NOS directory, so ADFS support for WS-Federation rather than SAML just complicates their lives.

Leaving aside the question of whether federation technology should be bundled with the OS, the fact is that Microsoft are only now beginning to fill the gaps in federation. They have chosen to do so using proprietary specifications (remember, WS-Federation is a specification, not a standard) rather than an existing open standard with wide adoption. It will be an interesting couple of years as enterprises make their choices. But again, choosing products using a common standard would have been so much better than having to bet on a spec.

Updated:

Comments

James

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.

James

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?

Superpat

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.

Superpat

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.

Michael

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.

Pat Patterson

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?

Leave a Comment

Your email address will not be published. Required fields are marked *

Markdown is supported.

You May Also Enjoy