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.

Your options are VERY limited

[Anonymous Coward]

Your best hope is to aim for password synchronization. Single sign-on sort of works, but it's very primitive.

I took part in a single sign-on test for a Fortune 100 company (NDA's prevent me from logging in, or saying who I worked for), but most products would synchronize passwords amongst major systems, then some sort of applet/program would run on your PC, and "remember" the passwords and logins to other systems. The host mainframe logins names were chosen through some arcane formula, which meant that login names/identities would never be the same. You would sign in to your PC, the Single Sign-On (SSO) program would grab your NT credentials, then start filling in your password and login name when it noticed it was needed. For the 3270 login sessions, the vendor provided either a custom 3270 terminal application, or a plugin, or just a screen scraper that would recognize certain characters, then fill in the name and password for the user.

It's about the same as the Mozilla/Firefox password manager. You supply one master password, and it remembers who you are and what you login with for a variety of sites. In this case, substitute applications for web sites.

The best hope is to go for a single master LDAP directory, and authenticate against that. You can then use it for an NIS domain for the legacy UNIX boxes, the NT domain or Active Directory can use it for normal PC's, and web applications can use it for logging in.

Old applications will HAVE TO BE RE-WRITTEN to use one of the above authentication methods. That will be impossible for several applications, and overly expensive for others. The best course of action is to weigh the cost of adding in SSO versus just writing a new version of the application from scratch.

Single Sign-On projects never become true "single" sign on. They are "reduced" sign on projects.

The question is, how much is it worth to you? It's going to cost some real money, and management has already indicated that it's not willing to pay. The best option is to move to the unified LDAP/NIS/Active Directory path mentioned above (which can really be done with a single Linux box running Samba and an LDAP server), require all new applications that are being created to use one of these authentication methods, then give other applications a five-year timetable to be updated, replaced, or eliminated.

Single Sign-On

[ProfFalcon]

I worked at a company that did single sign-on very successfully. We wrote a program that watched for the login prompts for each application. When the login prompt showed up, it just stuffed the login information in and hit OK.

It monitored Windows applications, web applications, telnet applications and even watched DOS prompts.

It stored the username/password information on a central server so you could use it from anywhere.

Since it's not free, the only reason I mention is is for some of the concepts. You can use Windows Scripting Host to do much the same thing. I've done a few simple 5 line scripts that monitored for a window to appear with a specific title, then stuffed the username and password in, then hit OK. Do that 50 times, once for each application and you are set.

The hard part comes in when you want to manage password changes, add new applications, etc. That takes some thought.

Doing this in KDE with DCOP is just as straight-forward. Start a project on SourceForge for Windows or KDE and I'll jump in and help. I would love to have a working open source single-signon application.

The Unix equivalent is Kerberos.

[Ayanami Rei]

You klog once... and you have a ticket that gets kept around for two hours or so (destroyed at logout).

Any "Kerberos-ized" application on your network will let you in as long as your ticket is valid.

Most every Unix-type thing got kerberosized at some point a few years back, mostly because they were all OSS (FTP, HTTP-AUTH, TELNET, IMAP, XWindows, AFS).

It didn't work for propietary apps, but there weren't a lot of those that didn't rely on host OS security in the first place (you might have an X-Session into the machine with the application), so you would use Kerberos there.