Slashdot Mirror

← Back to Stories (view on slashdot.org)

Single Sign on Solutions on the (Very) Cheap?

Posted by Cliff on from the if-your-security-isn't-broke dept.

ATMosby asks: "I was asked today to look into how a single sign on can be implemented. Now part of the constraint is that is must be very cheap (and by that the powers that be really mean free!) Of course there are all sorts of legacy applications that are 'required' to work with this, ranging from java applications to ancient pc programs. I've poked around a bit and found some pointers to commercial software that seems to be able to due bits and pieces of the job, but nothing that will do everything and anything that might be thrown at it. Before I just go and tell folks "No bloody way!" does anyone have words of advice to offer on the topic? Stories of successful or wildly unsuccessful attempts? Commercial or otherwise?"

4 of 48 comments (clear)

  1. Not necessarily hard.. by Jon+Peterson · · Score: 4, Interesting

    Normally, there's one obvious target for the mother repository - e.g. an existing Active Directory service for windows boxen, or an existing LDAP service or something.

    So long as you can get at the data in this 'mother service' then, it's usually just a case of replicating the data in places where the other little apps can get at it. This means users will only be able to change their password using the mother service, but will be able to authenticate against any of the read-only daughter services.

    So, if one of your legacy PC apps is hardcoded to authenticate against the user table in a database, then you write a nightly batch job that queries the mother serice (lets say it's LDAP), and writes the passwords into the legacy apps user table password column.

    Of course, if different apps use different one-way encryption for their passwords, you may be a bit stuck.

    --
    ----- .sig: file not found
    1. Re:Not necessarily hard.. by FacePlant · · Score: 4, Interesting

      Your answer is correct, but I'm afraid your solution is incomplete.

      The user directory is only half-the battle.

      It eliminates the adminstrative overhead of maintaing indiviual password stores for all of one's applications, but the whole of single-signon, in my experience has been to have the use sign-in once, and never have to authenticate to each indiviual application over the live of the login session.

      So once you have your directory, you need to have a mechanism for all you applications to query it, which may not be possible with old off-the-shelf software.

      So a breed of software has emerged which acts as a proxy between you and your login dialogs. This software, and I've evaluated one of them in a MS Windows environment, tends to call itself a portal. You typically let it record your clicks and keys as you log into an application, and then is stores that info [hopefully in a secure fashion] and when you run that application again, it runs the login script before handing control to you.

      So what can you do on *nix? Well, having not worked on that myself, I'll leave that answer to other responders, some of whom have already suggested a couple of applications to check out.

      cheers.

      --
      My Heart Is A Flower
    2. Re:Not necessarily hard.. by photon317 · · Score: 2, Interesting


      One of the central real issues behind the SSO problem is that existing directory services are just directory services - they have no concept of a session originating at a certain terminal or access point. Integrating "sessioning" into directory services in a way that's secure and useful to operating systems and applications is the key to doing SSO "right", where a user should only have to authenticate once when they sit down at their terminal to work on myriad systems.

      --
      11*43+456^2
  2. LDAP + Samba by Anonymous Coward · · Score: 1, Interesting

    Where I work we were faced with the same problem, people didn't understand that if you change your windows password you also had to log in to the unix servers. Most people didn't know unix, and this made changing them very difficult. Additionally, the big brass wanted to know why some long time employees had the same password since 1984 when the unix network first came online, and why they werent forced to change them.

    The solution we found, albeit messy, was to run LDAP plus Samba, forcing samba to act as a windows 2000 PDC and joining all the clients to that domain. This solved the password expiration problem, as we could set ldap values to tell samba when to expire user's passwords.

    Another solution you may want to consider (one that we looked at but decided against due to the inability to make passwords expire) is pGina, a free open replacement for the windows logon dlls. http://pgina.xpasystems.com/