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

OpenLDAP

[profet]

Think Active Directory without broken Schemas.

Most languages PHP, JAVA... have ways of using LDAP (even Active Directory) to authenticate.

Re:OpenLDAP

[gl4ss]

yes, but no fucking way is he going to get those legacy pc apps on it too(easily). what he is looking for is magic.

well.. maybe he could install bonzi buddy..

AcMaint

[joemc91]

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 t

roll your own?

[gabe]

George Schlossnagle's book [amazon.com] on Advanced PHP Programming includes an example single sign-on server implemented in PHP. You could just build one based on that code.

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.

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.

Kerberos I think should be a piece of the puzzle

[einhverfr]

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 w

Re:Not necessarily hard..

[Jeremiah Cornelius]

What you want - CHEAP is Microsoft's Identity Integration Server. It will sync LDAPs and AD. It will adapt to a handfull of other stores (NDS). If you have NIS maps, these can be pulled into the AD fold with the free Services for Unix 3.5.

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

[gooru]

If this is web-based, I highly recommend CAS [yale.edu]. It is used by numerous institutions around the world, and the license agreement is extremely flexible. And, it is free.

Re:CAS

[riley]

CAS works in small environments. Indiana University is using it and finding that it doesn't scale. It can't be scaled horizontally over multiple servers and doesn't fail gracefully.

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

[|<amikaze]

My university is using it just fine!

Re:Have a single login

[menscher]

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).

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.

Oops. One word on changing all those passwords

[Anonymous Coward]

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 pl

You need to provide more detail...

[EnronHaliburton2004]

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 d

LDAP or RADIUS

[bolix]

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?

[huber]

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.

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.

Re:Single Sign-On

[ccady]

Gee, that's a nice scenario for a thief. All s/he needs to do is to write a simple dialog with a certain title, and s/he can steal your passwords.

Environment(SSO + LDAP + ?)

[da_Den_man]

What is the mix of OS? What servers are being run? What are the majority of Apps ? Windows or Unix or?

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

[ATMosby]

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.

Without access to the source code?

[jotaeleemeese]

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

Re:A little clarification

[Chess_the_cat]

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.

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...

[wikinerd]

In my website [wikinerds.org] I use the following programs:

• 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.

Factoum

[DrSkwid]

Factotum [dotgeek.org]

Couple of additional ideas...

[rusty0101]

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

Roll Your Own

[autarkeia]

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

[perlchild]

Just how legacy are they?
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

[xenocide2]

Gator, or altria, if they don't know the name change. ;)

Not sure if what you're looking for is out there

[lkaos]

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.

This sounds like federated identity management

[GrassyKnowl]

This sounds like federated identity management.

There is an open source project that looks complete and comprehensive:

https://www.sourceid.org/ [sourceid.org]

OpenLDAP

[Chanc_Gorkon]

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

LDAP+Kerberos

[Michael Snoswell]

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 be

Novell has a product for Windows

[terminal.dk]

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.

Simple.

[WhiteWolf666]

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*

VERY cheap

[sulli]

Just use the same userid and password for everything.

Not very secure, of course, but it is a single sign-on.

Re:VERY cheap

[Proteus]

Just use the same userid and password for everything.

Not very secure, of course, but it is a *single* sign-on.

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

[Anonymous Coward]

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

Simple Online Remote User Authentication

[gpoul]

I'm not sure which kind of SSO you're looking for, but SORUA [sorua.net] might be an interesting thing to look at.

CAS & Shibboleth

[Edgester]

Try CAS
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]