Syntactic Confectionery Delight | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Change -- each site has a current system that works, and takes negligible effort to maintain.
I agree that is a main issue. Especially since there seems to be no simple (yet good) implementation of Single-Sign-On systems. Scalabilitiy issues I'd say distributed systems scale better. And from the view-point of any given site, it is only a 1:n relationship, and ideally would all use the the protocol, so that authenticating from different sites would not be a more complex task than sending emails to different domains (Email is also an n:n system that works....) Incompatable user names Yeah, you would need some map. But mapping your userid to your password (and probably email address) as is happening now, does not seem easier than mapping your (local) userid to the remote userid. Account management This could actually get a lot easier than it is now. The participating web sites do not need any password management system at all (since this is handled by the few identity providers). They just need to decide what sites to federate with. And for the user there is only a single place he has to go to manage his password (Actually, it does not have to be password-based at all, more complex systems like client-side SSL authentication that are just to difficult for small web sites to set up could be handled efficiently and transparently) Trust -- and this is the biggest one -- certified logins only work when everyone trusts each other This is the second main point. But if I wanted to start a Perl community site, where I just need to assign nicknames to people, without intent to gather email addresses, no online payment or such involved, I would probably trust the PerlMonks enough to let them handle my login. Also note that a password is never given to any site other than the user's identity provider. The web site he logs in to never sees it. In reply to Re^2: Single Sign-On?
by Thilosophy
|
|