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?"
Think Active Directory without broken Schemas.
Most languages PHP, JAVA... have ways of using LDAP (even Active Directory) to authenticate.
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
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.
-----
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.
Of course there are all sorts of legacy applications that are 'required' to work with this, ranging from java applications to ancient pc programs.
:)
You aren't giving alot of detail here. You didn't even mention your OS's.
Are these Windows apps? Linux apps? Web apps? Apps for your WPA-enabled phone (Hey, he said Legacy
Does each individual program really have it's own authentication system? If so you are in trouble. For most most legacy application, you log into Windows, then use the program. Somehow I don't think you are looking for more then just a centralized Windows network however.
Do people need to log into a website? How about Unix servers? Unix desktops?
94% of Repubs and 21% of Dems voted to renew the Patriot Act
Others have already recommended SSO software for web based applications. These usually include some kind of "plugin"/"extension" for the web server (servlet container, whatever), a centralized user database (that might be an existing Active Directory or OpenLDAP directory), and a "login-server" that plays cookie/redirect tricks to put everything together. Getting this working is not a piece of cake, but fortunately you can do it one service at a time: removing one sign-on is a good step towards single sign-on (but depends on how many servers you have).
Single-sign on for non-web-based stuff is more complicated. This involves usually two aspects: (1) making the "server side" (IMAP server, WLAN access point, SMB file share, client-server CRM application) to use your existing user database, and (2) setting up the client software that you don't have to enter the password. The latter depends very much on what clients you are using, but remember that even the first part might be useful without the second.
I'm confused, are you attempting to refine your security to the application level or looking to integrate your applications with a centralised security model?. These are separate and distinct requirements!
You need to provide more info to help us determine the exact capabilities of the "ancient PC Programs" and the nature of the access you intend to provide. It may be as simple as facilitating the centralised OS security-authentication and applying group level access-control to the application folder.For free authentication look to LDAP or RADIUS.
as lon g as the applications can be kerberized your all set. If your using MS AD then your already using kerberos, linux obviously can be setup with it as well as mac os.
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.
Single Sign On (dependent on the environment) can be as easy or as difficult as you and the environment make it. There are a ton of programs that ust block ALL access until sign in, and then they act as a 'proxy firewall' to the differing applications and processes based on a role or security priviledge attached to the account of the user. Most just pass the information in a Header of the requesting page. (ie. Username & Password). This would probably be the easiest method to implement with an LDAP implementation and either a PSP or Java based system. By passing the information of the user in the header, most programs were able to access and use the information without issue.
You keep going until you die..."Me".
Beats having multiple easy ways for hackers to penetrate the system.... Not to mention lusers are less likely to write down a single password (as compared to one for each system).
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.
- phpBB2
- Drupal
- Two installations of MediaWiki
- phpCollab
- Mailman
- WordPress
- etc
All these programs require separate login, but I am going to code a program for single login between most of these programs. If you are interested in this send me a mail so that I will remember you when I will have it ready.Factotum
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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...
No fscking way.
Any well behaved apps that use things like LDAP, NIS or NIS+ have hope.
If a smallish company that went out of business wrote an authentication protocolo of their own how are you going to leech your authentication system there? (maybe if it is text based you could use expect and provide the glue, but you are going to invent this, you are not going to find it anywhere).
Where I work we have single sign on, but that is the theory.
In one hand UNIX machines use one system, WIndows machines use another and Web applications uset yet one more (and some of them use Windows authentication). ANd we are a company that can throw resources to the problem and still have not managed to achieve this.
Unles you have the resources to do internal development this is a pipe dream. New application certainly should adhere to a standard that mandates single sign on of some kind, but old ones if they are not easy to convert should just be keot as they are until hoppefully they are retired.
IANAL but write like a drunk one.
I just had to write something similar for a client using XML-RPC and PHP. They have multiple entertainment properties, some of which they operate themselves and some of which are outsourced. They wanted a user to be able to sign up at any of their partners, search their local database of users, match up existing customer data if possible, and synchronize passwords. Then we built a single change password page, and now whenever a user needs to change his password all the partners direct him to the centralized page. The software then sends out an XML-RPC payload to each of the partners who have established relationships with the user.
The partners all maintain local copies of their records and can continue to function (without the option to change passwords) if for some reason our client's system goes down. In effect it works similarly to Passport. It was surprisingly easy to do, though it did take rigorous testing.
In retrospect an LDAP solution would have been more elegant but we had to think about getting the largest number of partners onboard at once, and a fairly simple PHP script is easier for most people to swallow than learning LDAP (which I am doing right now, and I must say that it is the worst-documented software I've ever seen since delving into Linux TTY/Serial port programming).
Just how legacy are they?g e/lasso.entrouvert.org
Now there are some free(as in DFSG) smartcard libraries you can get with any debian system, and I'm sure those libraries can be used with the smartcards at a pretty low fee. (I realize you meant perhaps a SSO without tokens, then you might look at the lasso libraries from http://freshmeat.net/redir/lasso/47082/url_homepa
However, thinking that rewriting those legacy apps as anything but expensive is not very realistic, and my definition of "Legacy" starts with "no source code" so you'd be really screwed in that situation.
If you can rewrite the auth libraries to inbclude something like lasso, you can be fine.
Gator, or altria, if they don't know the name change. ;)
I Browse at +4 Flamebait
Open Source Sysadmin
Here at Purdue we use acmaint to syncronize accounts and passwords between many different systems, including unix accounts, Active Directory accounts, email accounts, and any departmental accounts that you may have. For instance, I have accounts for the Unix computers, Macintosh labs (auths against Unix I believe), the main Purdue.edu Active Directory structure, Department of Statistics, email services, School of Technology, and the Computer Science department. My password is synced among all of them by this service. Check out http://directory.purdue.edu/MAIL-HUB/ed/fields/acm aint_explain.html for a little more info on it.
There is a big question here. What you need is a modular system which you can use to manage identities across the network.
Note that my solution listed here is not necessarily the most secure, but it is the one more likely to work with minimal engineering. If you want me to actually work with you see if I can put together a more secure system, please email me and I will be glad to do what I can. I do not work for free, however. You can see my web site for more on my business.
Anyway-- simplest solution would be a Kerberos user account system with various other modules which could plug in and authenticate against the Kerberos password. Doing a "plug-in" replacement may be difficult because I don't know what applications you have and how they authenticate. However, this is a basic model which you may find useful. The next step is to set up Samba to act as a domain controller and either authenticate (plain text) against PAM (hence Kerberos) or encryptes with password sync.
Unless you have an external authentication source for your Java applet, you will certainly have to port them to Kerberos or NTML authentication. If this is not an option for any app and no network authentication is supported, then you will have to exclude that app.
You can probably find other plugins you can use to authenticate using other protocols (OpenLDAP can authenticate against Kerberos or PAM, I think, and PAM can authenticate against Kerberos).
LedgerSMB: Open source Accounting/ERP
take a look at shibboleth
There was a guy trying to build an app that you describe. His idea was to proxy all network traffic and modify the password fields after some central authentication took place.
This works for trivial protocols like SMTP or HTTP but it doesn't work for very secure protocols. Protocols like Kerberos are tamper resistant so this just isn't practical.
int func(int a);
func((b += 3, b));
This sounds like federated identity management.
There is an open source project that looks complete and comprehensive:
https://www.sourceid.org/
OpenLDAP is THE way to go, but your apps have to support it. LDAP will also only provide authentication. It will nto controll your APPS security. Each app has it's own security that will end up being the bulk of your load. The biggest problem will be getting your proprietary, yet necessary apps authenticating to LDAP if it's even possible. We had one app where I work where it could not walk a LDAP tree and we have multiple directories that are geographically based. The app in question could only read one directory. We went through all kinds of rigamarole to get it to work but it finally worked pretty reliably...then the vendor released a new patch that negated our work (could walk multiple trees). Oh well....it will still work when we migrate to the new stuff. Also, one issue we run into is if we do this with our main app,our UNIX server can handle the authentication to LDAP (in our case, Novell eDirectory), but the application is not certified to run "that" way. So we stick to two signons, one for everything else and oen for the production system. That said, here's why I don't like single signon:
Once you get the one password, then all of the accounts for thtah signon are compromised. If you have a hole in ANY of the apps, that makes all of them vulnerable to attack. As much of a PITA it is for users, I don't care. I am not in a rush to migrate to using LDAP for our main application as I would rather the passswords be independent. Although most users make the passwords the same, I do have some that know why they should not have that practice.
Gorkman
We have started rolling out this across our project (300+ PC running Win2k and WinXP, about 20 Suns and 10 SGIs) and it's the best we could do. We weren't able to get our VAXes (yes, two of them!) to join in but besides that the rollout is going fine and no significant glitches (despite getting out SUN NIS+ password credentials out of sync when upgrading from Solaris 8 to Solaris 9 because Solaris 8 didn't care if local and remote credntials got out of sync!). (You can't use Win Servers as an LDAP server because it's non-standard, but will accept a unix based LDAP server for authentication.)
pithy comment
uses AD or LDAP as backend. Works with most Windows applications, since it can watch dialog boxes, enter correct info for you etc. Can also script applications like terminal emulators.
We have been looking at it, and it looks good. Can even use different passwords for different systems, all stored in your keyring. Can even handle password changes and pick random passwords.
But it is not cheap. Think $30 per user or so.
It is the Novell NSure SecureLogin.
Have everyone switch their e-mail to Hotmail, make everyone get an MS Passport, and then only use MS services.
.
Duh, any idiot could have told you that. . . .
*evil grin*
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Not very secure, of course, but it is a single sign-on.
sulli
RTFJ.
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/
I'm not sure which kind of SSO you're looking for, but SORUA might be an interesting thing to look at.
Try CAS
It's a free web-based single-sign-on
http://www.yale.edu/tp/auth/
Also, take a look at shibboleth
http://shibboleth.internet2.edu/