Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Single Sign-On?

by Thilosophy (Curate)
on Mar 06, 2005 at 11:08 UTC ( #437026=monkdiscuss: print w/replies, xml ) Need Help??

Fellow Monks,

outside of our monastry there are other centers dedicated to studying the script, and I am sure a great many of our brothers and sisters frequently travel there. Alas, they cannot enter as members of our order and have to join the ranks of another sect as well.

I (as most, I suppose) have a number of Perl-community related login accounts. The ones for Perl Monks and PAUSE are essential, but I had to get another one to vote for CPAN modules (which I hardly ever do as I cannot be bothered to log in most of the time), and I would probably also contribute a little to the new if I did not have to get yet another account.

Is there any chance for the various people running these sites to come up with some federated identity system that would allow a single sign-on? What are the big hurdles? Technical problem? Lack of a widely accepted implementation (we would want something done in Perl, of course)? Lack of trust? Improved sense of security due to having many accounts of limited power each (although you end up having to give passwords to many different sites, which could become a big problem if you always choose the same one)?

Or is that a bad idea in general?

Replies are listed 'Best First'.
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.

    1. 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.
    2. 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).
    3. Incompatable user names -- my PAUSE id is 'ONEIROS'. My 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).
    4. 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...
    5. 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.

      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.

      ++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.
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 uses -- namely trying to login to PAUSE by proxy. There were various concerns expressed and alternatives proposed, but, sadly, no resolution.


    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.

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:
    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:
    and an internal department site might recieve:
    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.
Re: Single Sign-On?
by jbware (Chaplain) on Mar 07, 2005 at 16:43 UTC
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™

      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".

        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.


        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

        You may be interested in looking into OpenID. It's just started, but there are some serious folks working on it.
        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.
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 :-).

      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.
      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
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
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).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://437026]
Approved by b10m
Front-paged by b10m
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2020-10-29 23:08 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (274 votes). Check out past polls.