One problem with distributed identity systems

August 13, 2007

From one perspective, using someone else's identity system sounds very nice. Imagine the convenience of being able to just use LiveJournal user accounts on your site, or (for an example closer to home) a central university database of campus-wide accounts.

(Yes, I am conjoining 'identity' and 'authorization' here, because I believe that it's what a lot of people do in practice when thinking about this sort of thing.)

The problem with this is that any time you use a distributed identity system, you are delegating the ability to establish and retract identities on your system to some remote third party. Even if you trust them not to be malicious, can you trust them to take (enough) action if one of their users is merely abusing your system?

The inevitable result is that attempts to use distributed identity systems generally grow at least local blacklists, and may have to go all the way to local whitelists. At this point you have less of a distributed identity system and more of a global identifier and outsourced password handling mechanism.

(Not that this is useless; users appreciate not having to remember yet another identifier and password.)

I believe that a genuine distributed identity system can only thrive within an organization, and only then when all of the bits and pieces involved have the same policies on use, abuse, and termination. This probably rules out universities, or at least large ones.


Comments on this page:

From 71.131.180.195 at 2007-08-14 12:36:12:

It does sound like you're not familiar with shibboleth, the federated/distributed identity system for the higher education community... http://shibboleth.internet2.edu/

-dave kearns http://vquill.com/

By cks at 2007-08-15 15:34:44:

From what I can see, I think you still have the same issues with something like shibboleth. For example, what do you do if a particular remote user at another university is abusing one of your services that you're offering to their university through shibboleth? Either you have a local blacklist, so you can turn off just that user, or you have to rely on the other university dealing with the situation both promptly and effectively.

(You are probably somewhat better off, in that you may have formal agreements about this sort of stuff between you and the other university, but that doesn't necessarily mean very much in practice.)

Written on 13 August 2007.
« Adventures in network design, illustrated by our new backbone connection
The benefits of growing your toolbox »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 13 21:30:54 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.