Federation v ESSO

It's well understood that achieving single-sign on in the enterprise is an admirable target. The complexities of rolling out such an infrastructure may mean that integrating all enterprise applications with a common security infrastructure will take some time (if it is even possible).

But what happens when single-sign on to a third party is a target?

Readers will already be aware that I am a fan of the concept of security federation but how many organisations have federation-aware applications? Over the last 2 years I have been met with a consistent answer to this question when broaching the subject of federation with third-parties. None!

Maybe we have just been unlucky with the third-parties we have been dealing with but I suspect the real answer to the question is still pretty close to "none".

So, do we force these third-parties to migrate to a federated security approach or do we just accept that our employees will have to have a separate UserId/Password for the third-party site/application? Or is there another way?

Well, I'm quite sure with just a little bit of effort we could provide a mechanism to automate the sign-on process on behalf of the employee. I'm quite sure that with a bit more effort, we could automate the process of changing passwords upon password expiry. I'm also reasonably confident that with (considerably) more effort, we could automate the provisioning process. And everyone is happy once more... until the third-party changes the various screens used for each of these functions.

You see, it would seem that most of these third-parties haven't even exposed an API catering for these functions.

However, the idea of scripting the logon process seems like a reasonable stop-gap until full federation is achievable and this is the focus of applications like Passlogix's V-GO suite (available at http://www.passlogix.com/). Indeed, this little application seems to tick so many boxes that the guys at Passlogix have struck deals to allow some of the big boys in enterprise computing to sell the software in rebranded form: IBM Tivoli and Oracle to name just two.

Are there any downsides?

• It is a client application that needs to be deployed onto the desktops/laptops within the organisation
• It is a Windows only application
• It doesn't seem to support Firefox

The upsides, of course, are that is should be a relatively quick and easy approach to achieving SSO with a third-party. I can't help thinking that an amalgamation of Password Safe and Auto-It could achieve the same thing.

• http://passwordsafe.sourceforge.net/
• http://www.hiddensoft.com/autoit3/

So, do I feel compelled to develop a freeware alternative to Passlogix's offering? No, I'm afraid not despite the fact it would be an interesting exercise. The additional features of V-GO would sway me towards buying the off-the-shelf package (although I have no idea how much it costs!)

And what about our federated security solution? Unfortunately, we are faced with a tricky situation. This type of solution requires both parties within the federation to have security federation aware systems. Deploying such systems is a "leap of faith" - faith that others will follow suit. Within my experience, none of our third-parties are ready to take that leap... yet!