Single sign-on models for a mixed environment

Question

I'm not entirely sure if this is the right site for this, but I'll give it a shot.

Basically, I'm looking into different ways of setting up a single sign-on service for an existing corporate environment. Within this environment, there's anything from old legacy systems to new web services, all running on different platforms.

I'm not really looking for specific solutions, as much as high-level approaches/strategies. I found a great writeup here, but it's from 1997, so it's not exactly up-to-date. If you know of a similar, but newer, paper, please post a link to it. If not, I would be eternally grateful if you were able to contribute with information on more modern models that haven't yet been brought up. If you have implemented such a system in a similar environment, I would be very interested to hear how you went about it, and why you chose that specific strategy.

If this question would fit better on another site, please leave a comment and I'll post it there instead.

Thanks!

Answer 1

If you try to implement a SSO system you have to distinguish two fundamental different solutions:

1. Server side SSO: in this approach every server application must use a central authentication system like a LDAP or it must trust some kind of ticket like in Kerberos or SAML or the authentication must be done with some kind of certificate.
2. Client side SSO: in this approach you have to use some kind of client software which automates the authentication process.

The advantage of Server side SSO is, that it can be implemented in a way that it gives you more security like a simple password authentication. But every server must be able to join the SSO system. In some cases this is technological complicated (SAML for graphical user interfaces other than the web browsers) and for legacy applications this may be a show stopper.

In those situations you have to use the client side SSO where some kind of software handles the authentication by sending login and password credentials to the input fields of the legacy application. This approach has a phishing weakness, because it is difficult for the client to trust the server, because a login window can only be identified by some kind of window title which can be easily hacked on every windowing system.

Rule of thumb: SSO in heterogeneous networks is complicated and very expensive.

Answer 2

Trying to migrate legacy applications onto a SSO system is very difficult. Even just setting up new off-the-shelf applications for SSO can be near to impossible.

A more achievable option (which paves the way to a true SSO implementation, and therefore should at least be considered as a prerequisite) is to use a consolidated authentication / account management system: your users should have a single user id and a single password to access multiple services.

LDAP is the obvious choice for this. That's not to say it won't be hard work - even starting with something like GoSA or MS-Active Directory you'll still need to create a consolidated user model and will probably need to adapt the default schema to some extent.