Single sign-on – Simple?

Single sign-on sounds pretty simple on paper. All that’s required is a federation server, and applications that support federation, and you’re off, right?

Well, think again. In reality, enterprise Single Sign On deployments tend to be anything but simple. As with any identity management technology, Single Sign On affects all users and reaches across the whole IT infrastructure, requiring often complex integrations.

In a perfect world, all of your enterprise applications will all support SAML, which would make implementing SSO very easy. But in the real world, you have a mixture of applications, some commercial software packages running on-premise, some home-developed applications, some open source and some SaaS applications, which all have varying levels of support for standards based SSO.

For some applications, you have full access to and can modify the code base, some are completely closed to you. Others, maybe managed for you by a third party, may lie somewhere in between. So whilst modifying applications to support federation might sound straightforward, in practice it can be difficult to achieve.

By way of example, in our recent enterprise SSO projects we’ve had to deal with several of these scenarios. We’ve had to work with a customer to enable a .NET application to support SAML, develop custom modules to authenticate users against a custom API rather than via LDAP, implement complex OGNL scripts to process attributes on the fly, and implement Open ID Connect alongside SAML and WS-Fed.

So what’s the lesson from all of this? Well, as with most things, the key is to have the right tools. To support these kinds of complex integration scenarios, you need a SSO server which has a) full support for all current federation and SSO protocols, as you can guarantee that in a typical enterprise they will all come into play if you are extending SSO across the estate, and b) a comprehensive selection of integration tools to help you when a standards based approach is not possible; such tools might include app or language specific integration kits, a SDK to enable custom elements, or just really good community support.

Based on our experience, we recommend PingFederate as having the broadest protocol support alongside the widest range of integration options. Other options such as ADFS can do a good job, and may look attractive from a licensing perspective, but for the reasons above it may prove challenging to build an enterprise SSO deployment around them.

So before embarking down this route, ask yourself if the technology you are choosing really has the features you need to get the job done? And if not, are you really choosing your technology for the right reason?