Give me federation or give me death
by Deborah Volk on May 20th, 2009

Once again, several threads coalesced and lead to this blog. The chief impetus was a question asked on LinkedIn about federated identity management. Since the term federated identity management is somewhat of a misnomer (and a broadside), we'll use an even less accurate but slightly more legitimate federation. To wit, the person asking the question was wondering if federation is "critical" and why organizations are slow to adopt federation for "cross-organizational access"

My response to the question was that federation is not critical and the reasons for slow adoption are mostly standard. It's a fairly new technology with a high level of complexity that requires very specialized knowledge to deploy. Moreover, deploying federation has a unique twist not seen elsewhere in identity or access management implementations. Instead of Oscar Wilde's "tyranny of the weak", we've got a situation more typical in the business world, "do as I say and say as I do".
The latter scenario plays out something like this. Company A has an internal intelligence service tasked with sending well-trained, combat-hardened and fearless pigeons to spy on the competition. The service is used by a lot of sales people, they interface with pigeons via Morse code. Prior to the move, the pigeons lived in the company's datacenter; empty server enclosures were recycled for nesting, effectively producing a very "green" space with low energy consumption. Alas, the pigeons were too costly to maintain. Besides food and water, they demanded training in latest crypto techniques and argued loudly (in Morse code) about pros and cons of Blowfish vs Twofish. All that tap-tap-tap unsettled the system administrators who had offices on the floor above the data center and rather than pay for psychological counseling due to stress, Company A decided to send the pigeons to a 3rd party provider (Company B) located on a small island in the Pacific Ocean. It is always sunny on the island with nary a cloud in sight.
Company A had an application that kept track of pigeons but Company B promised a better and shinier pigeon-tracking app with a web user interface that knew what you were going to type before your fingers touched the keyboard. Company A agreed to let Company B track the pigeons but it also wanted to know what the pigeons were up to so it asked Company B to allow Company A people to use Company B's application. To top it off, Company A did not want its users to be prompted for credentials by Company B, no sir, no how. Company A told Company B that (drumroll, please) "we are going to use federation to avoid impacting user experience". Company B didn't know what these ominous words meant, they're pigeon experts after all. They did what everyone else does in this situation, they hired a consultant. The consultant tells them that they may have to change the authentication (and potentially authorization) components in their app so that they can accept SAML messages from Company A. More expense, all for the convenience of a few Company A users who want to track pigeons. Company B decides to swallow the sword and bite the bullet at the same time and Do It.
What can be so hard about establishing trust between two parties and processing a SAML message, you may wonder? For the answer to this I will turn to real experts. Patrick Harding (CTO, Ping Identity), Leif Johansson and Nate Klingenstein (both Internet2) write in a recent issue of IEEE Security and Privacy on this very topic. To quote from the article:
SAML 2 is extremely flexible and offers many choices, but without much guidance about
what’s most appropriate. Today’s implementations generally do little to hide the resulting
complexity: administrators are often asked to provide answers to fundamental questions that
require deep insight into the SAML 2 standard. As an example, let’s review some of the points
that two organizations must address to successfully establish a federated connection:

  • How should trust between providers be managed?
  • How should information about providers (metadata) be provisioned?
  • Which SAML profiles and bindings should be used?
  • Which messages and what part of each message should be signed?
  • Which identifiers and attributes should be exchanged?
  • What are the semantics of those attributes and identifiers?
The article goes on to suggest a possible solution to the metadata exchange woes by making the protocol even more dynamic but I won't go there, I am scared. If a CTO from one of the top federation vendors and two very qualified gentlemen from an organization that gave the world Shibboleth (another federation Das Gift) think this is just a tad too complex, what are mere mortals supposed to do?
Last but not least, some of you reading this blog may wonder if I am not shooting our own company in the foot (pedestal?). After all, we get paid for helping customers figure out these issues and wouldn't it be better for us if the learning curve went from high to very high (Space Elevator high), we'd be in business forever. As much as I would love for us to be dealing with entities and metadata every day, we help our customers solve problems that are relevant to their business. Federation is a choice of technical architecture, perhaps an elegant one, but still a technical choice and it has an indirect impact on business at best. A few unique business cases aside where federation presents a competitive advantage, choosing one approach vs another is an exercise in humility. I'd like to think that if we can save our customers money they'd spend on us (among other things) by steering them into less choppy waters, we've done our job.

Posted in Access Management    Tagged with federation, SAML


Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)