IAM Myth: SSO First

Single Sign-On (SSO) is a service that is usually provided by a class of technology called Access Management. And there’s a good reason for that. Efficient SSO solution asks for user credentials just once. Then it needs to remember the fact that user is already authenticated. It needs session for this. That’s what access management does: session management. It also needs to pass the information that the user was authenticated to the applications. And also pass some data about the identity of the authenticated user.

But there’s one of the major drawbacks of this solution: for a SSO system to pass the authentication and identity data to the application the application must be able to receive them and correctly interpret them. But there is no universal way how to do this. There were several attempts to design a protocol for this purpose. And some (such as SAML) are really useful in some situations. But they are not universal. Vast majority of enterprise applications do not support any standardized protocol. If you are lucky then there is an agent for your type of application. But universal agents are usually available only for the simplest web application. Anything more complex needs to be customized. The original authentication mechanism of the application needs to be replaced by SSO agent. This requires a custom authentication plug-in if the application authentication is pluggable. Which is still quite a rare sight. Otherwise it requires a wild mix of source code modification, expensive professional services, even more expensive extensions to support agreements and/or a great deal of good old dirty hacking.

And there is another problem. Even if an application support a standardized protocol it is not easy to configure it. If the integration goes any way beyond simple "logged in or not logged in" the integration turns to a nightmare. Every application requires slightly different set of identity data. Whole project quickly turns into a large bowl of a very expensive spaghetti.

That’s still not all. There is one more issues that is perhaps the most critical one from the system architecture point of view. If a user has to authenticate with just a single password then there needs to be just a single password for each user. This means that there needs to be a single identity for each user. And each application needs to recognize that identity. User identifiers need to be aligned across applications. This may seem like an easy task but it is not. Not even close. And a single, authoritative database of user identities needs to be established. You may think that you have such a database. But it is extremely likely that it is not complete. It either does not contain all identities, does not contain every required attribute, has an incorrect format of the attributes or all of that at once.

Despite that many existing user databases are in fact good enough to start a SSO project. A lot of SSO projects starts with one or two applications that shared the same user database anyway (such as Active Directory). In such a case the start goes well. But this is a deadly start. It "proves" that the SSO idea is feasible and the project continues to spend more money and time. But even with large budgets only a very little can be achieved. Integration of each additional application is a nightmare. Such projects usually end up spending an unbelievable amount of money just to integrate 3 applications out of 30. This is usually very far from the original target and any chance of return of investment is practically lost at this point.

Never start an Identity and Access Management project with a SSO unless:

It is almost impossible to have such a level of confidence at the start of any IAM project. Therefore the best strategy is to start with a proof of concept. Do not choose the simplest applications for the proof of concept. That really proves nothing. Choose the most difficult application that you have. That helps you to estimate the total cost of the solution. Do the proof of concept before you commit to a particular protocol or vendor. Not all vendors have equivalent capabilities and the amount of work needed to shape each product is also vastly different. Once you determine that SSO is feasible at all you can start planning the project.

Perhaps the best way is this:

The crucial concern in any SSO project is user database. It makes absolutely no sense to start a SSO project if the user database is in bad shape. You won’t be able to finish such project. That’s also the reason why most successful IDM project do not start with SSO at all. In fact SSO is usually the very last item on the identity management TODO list. Typical IAM project starts with the other two crucial components first: identity store and IDM system. Why do you need them?

In fact the directory service, identity management and access management works together very well. So well that many projects are fundamentally based on this combination of technologies.

That’s right. Maybe the problem is in the question, not in the answer. Maybe it is not SSO what you really need.

It is usually not a problem for a user to enter the password several times per day - as long as the password is the same. This is almost the thing that SSO would do. The difference in the benefit of this almost-SSO solution and a real SSO is surprisingly small. But the difference in cost is huge. Because this almost-SSO solution can be implemented by using a simple IDM system. A IDM system that you would need to get real SSO anyway. Therefore there is almost no additional cost. But you can save a huge amount of money and time by not integrating the application user interfaces - which is the most expensive part of the SSO project. The users will just use native unmodified user interface of each application. The IDM system will make sure that the password are synchronized and therefore are the same all the time (or that there are two different passwords for two security zones and so on - you name it). This alternative costs only a fraction of the huge SSO cost and it brings a large proportion of the benefit. But the best thing about this approach is that nothing is wasted. If you choose to go for SSO later you can do it on top of the identity store managed by the IDM system. All the investments are reused.

There are also other alternatives to "true SSO" approach. "Enterprise SSO" (ESSO) is using agents that are installed on every workstation. The agent watches when a login window is displayed and enters username and password before user notices anything. It is something like "remember password" feature in browsers but much faster. It does not require modification of the applications therefore the deployment is much cheaper when compared with true SSO. This may sound as a good idea. And it may in fact be a good idea under some circumstances. But you have to make sure that the passwords are managed and transported in a secure way. And in any non-trivial deployment it needs to be integrated with a IDM system anyway. Therefore it is worth considering whether this approach brings enough benefit to justify its cost and potential security impact. And even worse the whole ESSO idea seems to be not entirely compatible with the new Bring-Your-Own-Device (BYOD) world.

Technology often called "Identity Gateways" is yet another alternative to the true SSO. The identity gateways is a kind of reverse proxy that fills in username and password in the web login form automatically. It is in fact it is a web-centric equivalent of ESSO. Therefore it has much better compatibility with current technology trends. It also does not require modification of the application therefore the cost of the deployment may be acceptable. However many of the ESSO-like concerns remain - such as security and integration with the IDM system. Yet this may be a viable alternative for some environments.

Overall the SSO is not an easy target and it is definitely not cheap. Therefore it is more than worth exploring the alternatives before you rush yourself full speed into a risky and expensive project.