Skip to end of metadata
Go to start of metadata

Tired of all the passwords? Who isn't. Wouldn't it be nice to forget them all and just have one? And enter it only once? Single Sign-On. That's what we really want! That's what we need! So, let's get it as fast as possible. Let's start an identity management project with Single Sign-On.

Oh yes. You can do it. But you should start preparing your boss that a very expensive disaster is likely to happen in a near future ...

Single Sign-On

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.

Solution

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

  • You are absolutely positively sure that you have a complete user database that can work for all the applications which you plan integrate.
  • You are sure that the cost of integrating applications to the SSO if feasible.

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:

  1. Conduct a proof of concept of similar realistic evaluation of proposed solution to make sure it is feasible and how much effort it takes to implement.
  2. Evaluate the state of user database. Compare the chosen user database with user database of all the applications that you plan to integrate.
  3. Based on the data from previous steps choose the applications which to integrate and which not to integrate. Remember, it is almost never feasible to have 100% integration.
  4. Estimate project cost, plan the project.
  5. Review the cost, compare with benefits and decide whether to start the project at all.

User Database

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 provisioning system. Why do you need them?

  • Identity store is an unified user database. It contains consolidated information about users of the information system. It is usually realized by a directory service (e.g. an LDAP server). This is usually the database that is used by the SSO system.
  • Provisioning system is a system that manages the user database. It synchronizes data between data sources (such as HR and CRM) and the identity store. This is a crucial component to keep the identity store up to date as it is usually not feasible to maintain the identity store manually. The provisioning system also makes sure that applications have all the data that they need. E.g. it can create and delete user profiles in the applications in almost real time. Therefore the resulting SSO system may be much simpler. Instead of spaghetti of identity data it may just take care of user identifiers which is much simpler. This considerably reduces the cost of SSO solution.

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

Do I Need SSO At All?

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 provisioning system. A provisioning 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 provisioning 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 provisioning 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 provisioning 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 provisioning 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.

See Also

External links

  • No labels