Slashdot Mirror
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?"
George Schlossnagle's book on Advanced PHP Programming includes an example single sign-on server implemented in PHP. You could just build one based on that code.
Gabriel Ricard
If this is web-based, I highly recommend CAS. It is used by numerous institutions around the world, and the license agreement is extremely flexible. And, it is free.
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.
When passwords age, and have to be changed, you had to go in to each system, change the password, then go into the vendor provided password manager, and tell it what all the new passwords were. There wasn't an easy way to set the new password, then have it propagate out to all the dependent systems.
That part alone stopped the company I was consulting for from going with a commercial SSO solution, and instead required all applications to use LDAP authentication.
Very often you can provide custom DLLs or plugins for programs where you can provide your own authentication mechanism. For NT, tye gina.dll (some name like that) can be replaced with your own login system.
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.
Simply stating [Citation Needed] does not automatically make you insightful or brilliant.
Thanks for all of the suggestions so far. The problem as I've been able to understand it is that there are complaints form folks that "I've too many passwords to remember, and I'm always having to type passwords." Some of the apps seem easy to modify, many of them are home grown java applets called from some web server environment. The ones that seem more difficult (impossible?) to deal with are the ones that either 1) we don't control any source code to (pc based) 2) we don't control where the software lives (accessed over the net via pc applications controled by the vendor) or 3) logins to alien systems. I was told by the powers that be, "find an open source program that will allow our users to automatically log in to anything, sort of like the auto compleation function that works for some web browsers." Poking around on the net there seems to be some very pricy software that will do this function for all software, given a sufficantlly small defination of "all software". Fun, eh? Again thanks for the stories, tips and links you can provide.
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Where I work, we also have a wide variety of systems that we have to log into, some daily, some weekly, some monthly, and some a couple of times a year. As an example of the daily stuff, I have to log into the PC (obviously) our ticketing system, a database (several times actually, don't ask) OpenView, a couple of other monitoring apps, as well as sevral pieces of hardware that depending upon their type have different passwords and different rules for passwords. There are even situations where a single device type uses different passwords depending upon where it is in our network. (On top of each requiring two different passwords, one to access, the second to manage.)
Corporate rules are that you are not allowed to write down passwords. If you forget a password for a device, see your lead. If you forget a password for your own accounts, you may be able to get them reset by the corporate help desk. Additionally it seems that no-one has been able to standardize on a single password philosophy. Some devices require 6-8 characters, alpha-num, Others max out at 7 characters. A couple require 6 or more, but requires at least one 'special' character [`~!@#$%^&*()_+=-{}|\":;'?>,./] as well as at least one number.
All passwords are changed at least twice a year, account passwords are required to be changed at least 4 times a year, but different systems have different schedules, including different durations, (Mainframe every 60 days, unix boxes not less than 30 days, nor more than 60 days, windows every 60 days with a 14 day notification period.
So, a few of us have dreamed of a viable single signon solution. I might even use substandard tools if they still allowed me to get my job done, and would take care of the signons for me.
I can handle a lot of devices with expect scripts, however even there some of the devices are visiable only from different system than my own, which means that the expect script would have to handle logging into another system, then from there connect to a second, and possibly third system. There are some changes going on in the system regarding how to access these devices as well, so an expect script would have to be able to be modified for all users to handle those changes.
Note that third party authentication is used in some cases. I have web pages that are authenticating to that database I mentioned earlier, but only in the sense that you provide the same account and password, not checking to see if you are already approved.
Most, if not all, of this could be 'automated" or handled by some of the off the shelf Single Sign On utilities, or even with Kerberose, except for that minor quible over password philosophy. The quible over password philosophy is a symptom of a greater disorder, which is that there are too many people who think that their system requires a different security level than everyone else in the enterprise.
As a result it is going to require direction from the very top of the company to get everyone on the same sheet of music. And that direction is probably going to have to advise people who think that they should have their own security systems in place that they need to get on board the new policy, or they can say goodby to their paycheck and someone else will be doing their job.
On thing to consider is that it is the very rare app that is out there that requires it's own signon that does not have a competitior (possibly less feature full) that does support a single sign on.
Yes you are going to have people complaining that the new tool does not have this or that specific feature. Telling them that you are going to file a bug report with the developers, may not satisfy them. You may have to support a legacy application or two until that feature is included. You may even have to look for another tool entirely.
It won't be cheap. Even if every tool you end up using is free, or open source, you are still going to spend time and money getting them set up, testing them, making sure that they all work well through password changes, or other authentication updates.
Good luck.
-Rusty
You never know...
Go price similar solutions from Netegrity, enTrust or Obelix. It's a no-brainer.
No matter how this is handled, there is always a SMOP (small matter of programming)! At least, MIIS provides an API that lets this be in VB. We are taking about running quickly. Anti-VB flamers will be required to submit code examples of directory / container syncronization with multiple password hashes of varying salts - in J2EE.
"Flyin' in just a sweet place,
Never been known to fail..."