Re: Single Sign-On?
by jhourcle (Prior) on Mar 06, 2005 at 14:00 UTC
|
As someone's who's had to deal with the 'single sign-on' concept before, I can mention a few of the bigger items that I've run into. - Change -- each site has a current system that works, and takes negligible effort to maintain. You are asking each site to modify their authentication system, which has the possibility of breaking their site.
- Scalabilitiy issues -- You can either set up one large centralized authentication system (LDAP, Kerberos, whatever), or set up some way for each site to authenticate off of the other sites. So it's either a single point of failure, or n(n-1) complexity (and becomes more complex as new sites are added).
- Incompatable user names -- my PAUSE id is 'ONEIROS'. My perl.org id is 'oneiros', and my id on here is 'jhourcle'. You would have to add complexity to deal with the fact that names may not map from system to system, and that the same id may be used by two different people across the systems. Trying to unify the systems after the fact is a massive PITA -- you can have each person create a new unified account, and then map all of their existing accounts back to it, but you get bickering when someone takes a userid that's been long associated with someone else (even if only one one system).
- Account management -- You need a way for sites to request password changes, or information changes, or to recover lost passwords, or whatever might be needed. Which leads us to...
- Trust -- and this is the biggest one -- certified logins only work when everyone trusts each other -- no one's going to authenticate as the wrong person, or otherwise claim to be someone else. They're not going to cache a password so that they can use it to gain access they might not have otherwise had. (AdminA on SiteA logs into SiteB. AdminB steals AdminA's credentials, so they can get admin access on SiteA; Or HackerC gets into SiteB, and then uses that to gain abnormal privs on SiteA and the rest of the network)
I'm not going to pretend that there aren't advantages to the users for single sign-on, but it is a royal pain to administer, especially if you're attempting to retrofit it into systems that already have active accounts. Yes, it's possible, but there's a good chance that the risks and headaches that it would entail aren't worth it to the various site admins -- especially as it might be something that they aren't familiar with, and so it'd be a complete unknown risk. If this is going to happen, I would assume it would start small, either centralized around one person who can unify the various sites, who is well trusted, and would take responsibility for the whole thing; or two sites who trust each other would band together, and possibly later add other sites into their circle of trust. I definately don't think this is as easy as someone saying 'make it so', and it happening overnight.
| [reply] |
|
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.
| [reply] |
|
++jhourcle and ++Thilosophy
I am currently in a group developing a community of role-play web sites. Usernames here are not just nicknames but characters played. An ideal system would utilize Single Sign-on to maintain each character identity through the various "worlds" (sites).
Having said that, your points #2, #4, and #5 are spot-on. No one is getting paid for this work on our hobby, let alone it being their job. When (not if) the SSO has a problem, the entire community will be down until someone (me?) gets home at night.
---
The harder I work, the luckier I get.
| [reply] |
Re: Single Sign-On?
by xdg (Monsignor) on Mar 06, 2005 at 14:36 UTC
|
There was a bit of discussion about this on the module-authors mailing list after CPAN Forum was announced.
One of the posts discussed the hack that rt.cpan.org uses -- namely trying to login to PAUSE by proxy. There were various concerns expressed and alternatives proposed, but, sadly, no resolution.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
Re: Single Sign-On?
by Anonymous Monk on Mar 06, 2005 at 22:38 UTC
|
see Shibboleth
here at university i login *once* and am authenticated via
local mechanism. i can now visit napster and they recieve
something like:
SHIB-USER: 76e4f594477c4121b3b560548dc8229e@uni.edu
SHIB-AFFILIATION: member@uni.edu
so they don't really know who i am, only that i'm from the
uni and have a uniq-id.
an internal uni site might recieve:
SHIB-USER: me@uni.edu
SHIB-AFFILIATION: member@uni.edu, staff@uni.edu
and an internal department site might recieve:
SHIB-USER: me@uni.edu
SHIB-AFFILIATION: member@uni.edu, staff@uni.edu
SHIB-DEPARTMENT: Information Services
SHIB-EMPLOYEE-ID: 85493
SHIB-OFFICE-EXT: x74393
Shibb has had some growing pains but has gotten much better
the past year or so. the auth parts are handled by an
Apache module so the application just needs to pull the info
from the environment variables.
Shibb could be used to allow Perl Monks, PAUSE, cpanforum
and others to trust eachother without sharing passwords
back and forth. | [reply] [d/l] [select] |
Re: Single Sign-On?
by jbware (Chaplain) on Mar 07, 2005 at 16:43 UTC
|
| [reply] |
Re: Single Sign-On?
by saskaqueer (Friar) on Mar 06, 2005 at 11:51 UTC
|
This sound like M$ Passport, and we all know how well that idea went. Just think of it that way, and you'll figure out that it's just a Bad Idea™
| [reply] |
|
If I understand M$ Passport correctly, they have a centralized registry that manages all user authentication. That is obviously not good.
However, it does not have to be this way, it can be a federated system consisting of a number of identity providers, and an even greater number of web sites that accept login authentication from at least some of those providers. For example CPAN forum could have a button in addition to its login box that PerlMonks can just click and they will be logged in using the PerlMonks system. They could have another such button for Slashdotters. This would not create any new "trusted third parties".
| [reply] |
|
Just so I understand you correctly, you're suggesting having x-odd buttons on every sites' main page, each one saying "log me in with my perlmonks account", "log me in with my CPAN account", "log me in with my foobar account"? This is MS Passport, except that instead of a one-to-many relationship, you have a many-to-many relationship. Also, it would probably require a major infrastructure change so that external sites can try to authenticate against your login credentials.
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
|
|
You may be interested in looking into OpenID. It's just started, but there are some serious folks working on it.
| [reply] |
|
Username conflict is the biggest problem with this, unless the system is designed that way from the beginning. I think CPAN->PerlMonks is a bit of a stretch, but I don't think it would (incredibly) difficult to have shared logins across a shared codebase like PerlMonks to Slashdot to Everything to JavaJunkies.
| [reply] |
Re: Single Sign-On?
by crenz (Priest) on Mar 09, 2005 at 09:44 UTC
|
Frankly speaking, I feel the effort is not worth it. For this kind of sites, I am comfortable with storing the password in the browser (especially since I can manage the passwords neatly with Mac OS X' keychain). This is much easier for me than to ask people to implement a single-login system :-).
| [reply] |
|
I use MacOS's keychain as well, and an encrypted text file as a backup. Keychain IS single-sign-on. It could technically work the same way with a 3rd party administrating, if you could trust them enough. For many people (myself included), this trust issue means that MS was the absolute least qualified company imaginable (with the possible exception of SCO) to launch something like that. Most people trust their own machines more than any companies, thus it works better that way.
| [reply] |
|
That is basically how I feel. I do seem to loose alot of my username and passwords when I run one my disk cleaning utilities without disabling the browser password manager option. I have found this tool extremely useful...
Access Manager
~crypix
| [reply] |
Re: Single Sign-On?
by ady (Deacon) on May 20, 2005 at 05:42 UTC
|
Couldn't a client-side solution like accountlogon solve the problem?
Of course the client ought to be in Perl, and thus portable across a range of OS'es... (There doesn't seem to be any such module available on CPAN tho...)
-- allan
| [reply] |
Re: Single Sign-On?
by Anonymous Monk on May 20, 2005 at 02:29 UTC
|
The LiveJournal people have launched a new SSO project that seems interesting. It is called OpenID and works without a central registry. You log in with the URL of your blog, which in turn contains the URL of your identity provider in a FOAF file. There can be any number of identity providers (OpenID plans to release a reference implementation of the necessary software), so you do not have to place your credentials with someone you do not trust. Of course, now the problem becomes what identity providers a web site can trust. But for low-security systems like blog comments OpenID should work fine, and for a loose confederation of Perl sites it should work as well (especially one-way: your own small site could just accept all PerlMonk and Slashdot user IDs). | [reply] |