eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
It was bad enough for retailer TigerDirect to find itself displaced in search engine rankings by Apples Mac OS X 10.4, with its own well-promoted Tiger nickname. (District Court to TigerDirect: “Get over it.”) Things are much worse this morning for anyone other than Microsoft and Sun with a pitch to make for federated identity technology. The two companies Friday announcement of single-sign-on standards collaboration has swamped the Web with well over 200 nearly identical stories, as of this morning, discussing the prospect of unified access to Liberty and WS-family architectures.
Its not hard to find arguments in favor of single sign-on. Setting up separate accounts for every user on every Web resource, even if the only purpose is to track usage of free services rather than actually securing sensitive assets, is costly and inconvenient. Users spend time logging on and seeking password assistance. Overwhelmed by the number of separate passwords and user names that they must manage, users adopt insecure practices including use of a single (and often obvious) password for multiple sites, often combined with automatic-login facilities in Web browsers that effectively authenticate the device rather than the user.
But if its clearly a bad idea to juggle too many separate eggs, its at least as bad an idea to have all ones asset-protection eggs in one basket — or perhaps I should say, to protect them all with a single lock, which is in effect what happens with a federated identity scheme. If you have access to any system within a circle of trust, you have some degree of access to every other system that shares in that trust relationship. Thats why its a terrible idea for the convenience of single sign-on to get too far ahead of the rigor of user authentication, or to outpace the discipline and accuracy of our definitions of trust relationships.
Its a mistake to compare one mess to another, and to say that the less messy approach is ipso facto better. The current situation of separate accounts for separate services creates tangible costs, granted. Those costs would be reduced with a more streamlined system of single-sign-on technology, no question. IT vendors would like to sell that technology, and IT buyers would like to substitute that capital investment for the continuing costly labor of administrators and the unproductive lost time of users, clearly.
The mess that we have now, though, is modular. Any individual user, or any given organization, can deal with that mess in an appropriately tailored way. I can use automated login facilities on my browser to reduce the burden of managing multiple passwords, and keep my laptop computer in a locked box when Im not using it. An enterprise business unit can build its own portal to consolidate access to many separate resources, giving each user an individual privilege bundle through that portal and thereby having any desired degree of granularity in control and auditability of resource use.
Premature introduction of federated identity tools replaces the modular mess with a monolithic mess — one that any given participant finds difficult to accept on any but an all-or-nothing basis. Its all too easy to envision a chain of trust with invisible weak links that are unknown to some of the members of that trust relationship: How many different administrators might become points of failure for proper configuration of systems? How many different platforms, each with its own vulnerabilities, might now become a means of entry into the circle?
A balanced analysis of single-sign-on offerings must consider the intended audience for a service, and the degree of convenience that those users will demand. It must consider the actual value of the assets and the transactions being protected, and the potential added value of greater convenience compared to the added risks of extending trust. It must consider the need to replace the technical barriers that currently divide our systems with the contractual protections of service agreements, clearly spelling out the obligations for due diligence in protecting trust partners from each others errors or misfortunes.
These are the things that must be done to avoid replacing a simple, understandable mess with a mess thats more complex, potentially less secure, and quite possibly more difficult to fix.
Tell me why youll federate anyway, or what youll want to see first, at [email protected].