Posts Tagged ‘Federation

The official Windows Live ID logo. Opaque back...

One of the leading providers of IT management SaaSQuest 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 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.


Microsoft’s TechNet EDGE posted a video with quite detailed discussion of Systems Management as a Service concept, example of such a service (Quest OnDemand), how it uses Windows Azure as the underlying technology, the security model behind it, and so on. Obviously a demo is in there as well.

Check out the video here.

Security and data protection are key concerns for any cloud solution. I truly believe that this is also one aspect that you cannot just improve over time. No matter how agile you are security needs to be there by design.

Unfortunately most cloud vendors/SaaS-providers still don’t tell enough about the way they protect customer data – which we know is a bad idea.

From that perspective you might find this case study which Microsoft has just posted worth reading: Systems Manager Offers Security-Enhanced, Hosted Solutions with Programming Framework. The case study lists some of the technologies used in Quest OnDemandQuest Software’s Systems Management as a Service product family.

There’s more to security than just encrypting internet traffic. The case study discusses how latest technology such as Windows Identity Foundation and Active Directory Federation Services 2.0 helped us make sure that customers are always in control of their data, which includes not just protecting data from those who should not have access (including Quest’s own engineers!) to it but also a convenient and secure way to delegate access to those who should.

I hope this helps you get a good overview to one of the approaches to cloud security. Read the case study here.

RSS My company’s main blog

My Recent Tweets



The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer Jelastic or anyone else for that matter. All trademarks acknowledged.

© 2008-2012 Dmitry Sotnikov

%d bloggers like this: