Opinion: Convenience mustn't outpace authentication and accountability.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 peter_coffee@ziffdavis.com.
Application Development 
