Single Sign on Solutions on the (Very) Cheap?

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

Comments

Not necessarily hard..

[Jon Peterson]

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.

Re:Not necessarily hard..

[FacePlant]

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.

Re:Not necessarily hard..

[photon317]

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.