CloudEnterprise.info

One of the leading providers of IT management SaaS – Quest OnDemand – has decided to stop using federation with Live ID as its main user authentication method and switched to simple email address/password way.

In the age of everyone trying to federate with everyone else this move seems to be going into the opposite direction. It turned out that in this particular case – IT professionals signing up for a service – found having to use a third-party identity to be not intuitive and had privacy concerns about the same identity being used for different levels of access to various services from different vendors.

Let’s have a look at what was the rationale behind choosing Live ID initially and then abandoning it. I hope that these lessons learnt will help more thoughtful discussion of when and what kind of federation is the right one to use as opposed to someone one-sided perspective the industry seems to have at the moment.

Why Live ID?

Quest OnDemand is a set of online services for Windows IT professionals. The services currently available include eventlog management and AD backup and recovery. Considering that these are primarily used by IT professionals in the Microsoft world, and that Microsoft uses Live ID (also known as Microsoft Passport or MSN Passport) as a way to authenticate for all Microsoft’s services, it made total sense to let users sign into the new service with their existing Live ID accounts instead of making them register new ones.

When we launched Quest OnDemand in June 2010, anyone interested in any of its services could just come to portal.ondemand.quest.com and sign in with Live ID credentials.

What went wrong?

Once we launched we got overwhelmed by our users telling us how confused and frustrated they were.

The complaints seemed to fall into a few categories:

Confusion about Live ID

Surprisingly enough, a lot of people don’t realize that Live ID is an authentication system which can be used across other web properties from various companies. A lot of people don’t know that what they are using to post to Microsoft’s forums or access their hotmail account is indeed Windows Live ID.

Users signing up or deciding to try a service from your company want that to be a business between them and your company, and are not expecting a third party to get into the mix.

Broken workflow

User experience suffered from users being taken away to another site with different look and feel during their registration process. When user already had a Live ID and used it to sign-in this was not as bad – she was taken back to Quest OnDemand upon authentication. However, if a new ID had to be created user was taken away completely, asked a lot of unrelated questions such as date of birth, and then not brought back to the original site.

If you want your customers to survive your sign-up procedure you need to control the account creation experience – just redirecting them to a third-party site does not work.

Privacy concerns

Even though all Quest OnDemand wanted to know about customers were their Live ID logon names (for example, to be then used as handles for delegation purposes) Live ID in theory holds keys to a lot more data including for example hotmail address book. From the web user interfaces customers could not clearly see that they are not accidentally providing access to their private data and as result did not want to proceed with the delegation.

Using primary ID seems to be a big commitment

Email address is a much smaller commitment for a service sign-up than some sort of credentials you are actively using as your core identity. If I try a service and I don’t like it worst case – the vendor will send me some email from which I will need to unsubscribe. If I share the ID I am actively using it kind of feels like I am committing myself in a bigger way and will not have the flexibility to easily go away, and then maybe come again some other day and so on.

The industry has trained customers to supply email addresses pretty much for any sort of access – now this is what people are expecting to use for sign-ups.

What’s there now?

Starting last Friday, Live ID is gone (obviously with all existing customer profiles and data migrated) and we are back to simple email address and password sign-in process.

The benefit is that although there is indeed yet another password to keep in mind (or to reset every now and then when you forget it), the web site behavior is completely expected and well understood by anyone, and the sign-up process includes way smaller number of steps and is easier to follow.

Is federation dead?

Not at all. There are multiple other cases in which identity federation makes total sense and makes users’ lives easier and solutions more secure. For example, while dropping Live ID, Quest OnDemand still has Active Directory Federation Services (ADFS) authentication option for enterprises federating their local Active Directory with Quest’s cloud. In fact, this is the only way Quest’s own employees (for example, technical support) can log onto Quest OnDemand. In this case, federation has clear advantage because it provides tight access control and ensures that only authorized Quest employees access the service and the access happens under strict corporate control.

There are cases in which federation works great and is the best way to implement user access to your system. There are cases in which it is not. Carefully evaluate your options and find which solutions works best for your customers!

Did you have similar experience on federation either not working or quite opposite solving your problems? If so – please share.