Single Sign on Solutions on the (Very) Cheap? 48
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?"
OpenLDAP (Score:3, Insightful)
Most languages PHP, JAVA... have ways of using LDAP (even Active Directory) to authenticate.
Re:OpenLDAP (Score:3, Funny)
well.. maybe he could install bonzi buddy..
AcMaint (Score:1)
roll your own? (Score:4, Informative)
Not necessarily hard.. (Score:5, Interesting)
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.. (Score:5, Interesting)
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.. (Score:3, 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.
The Unix equivalent is Kerberos. (Score:5, Informative)
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.
Kerberos I think should be a piece of the puzzle (Score:2)
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 w
Re:Not necessarily hard.. (Score:3, Informative)
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-V
CAS (Score:3, Informative)
Re:CAS (Score:1)
Single sign-on systems are difficult to get working with software systems that are not designed for them. I'd be wary of going down that path. It is a quagmire of time and resources to get running and keep running.
Re:CAS (Score:2)
My university is using it just fine!
Re:Have a single login (Score:3, Insightful)
Your options are VERY limited (Score:5, Informative)
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.
Oops. One word on changing all those passwords (Score:1, Informative)
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 pl
You need to provide more detail... (Score:2, Insightful)
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 d
LDAP or RADIUS (Score:4, Insightful)
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 [openldap.org] or RADIUS. [xs4all.nl]
Kerberos? (Score:1)
Single Sign-On (Score:5, Informative)
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.
Re:Single Sign-On (Score:2)
Environment(SSO + LDAP + ?) (Score:2)
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 requestin
A little clarification (Score:3, Informative)
Without access to the source code? (Score:2)
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
Re:A little clarification (Score:2)
Why make it so difficult then? Just use something like Keywallet [keywallet.com]. Everyone's happy again. They don't have to remember or type their passwords and it autogenerates very secure passwords for each app/site for better security. It's even free.
I am about to do something similar... (Score:1)
Factoum (Score:3)
Factotum [dotgeek.org]
Couple of additional ideas... (Score:4, Informative)
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
Roll Your Own (Score:1)
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
Legacy Applications? You gotta be kidding (Score:2)
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 g e/lasso.entrouvert.org [freshmeat.net]
However, thinking that rewriting those legacy apps as anything but expensive is not very realistic, and my definition of "Legacy" starts
give em what they asked for (Score:2)
Not sure if what you're looking for is out there (Score:2)
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.
This sounds like federated identity management (Score:1)
There is an open source project that looks complete and comprehensive:
https://www.sourceid.org/ [sourceid.org]
OpenLDAP (Score:2)
LDAP+Kerberos (Score:2)
Novell has a product for Windows (Score:2)
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.
Simple. (Score:3, Funny)
Duh, any idiot could have told you that. . . .
*evil grin*
VERY cheap (Score:2)
Not very secure, of course, but it is a single sign-on.
Re:VERY cheap (Score:2)
No, it's a single identity. Single sign-on doesn't mean "same authentication for everything", it means that I log in *once* -- to my domain account -- and everything else is transparently authenticated until I log out.
In theory, with SSO I should be able to sit down and log in when I get to work, and never enter my password again until after I log out for the evening (and when I lock PC in be
LDAP + Samba (Score:1, Interesting)
The solution we found, albeit messy, was to run LDAP plus Samba, forcing samba to act as
Simple Online Remote User Authentication (Score:1)
CAS & Shibboleth (Score:1)
It's a free web-based single-sign-on
http://www.yale.edu/tp/auth/ [yale.edu]
Also, take a look at shibboleth
http://shibboleth.internet2.edu/ [internet2.edu]