Federated authentication: security that makes you money

Federated authentication: using the same login details across multiple organizations and services; it is one of the few security technologies that can actually be revenue generating for end-user (non security vendor) businesses. There seems to be so many reasons to adopt it, but it is still a hard sell and does not have widespread implementation. However we maybe reaching a tipping point where this may all change.

I want to get something out the way first of all, any writing on federated authentication can get bogged down in using one identity everywhere. Governments in particular, all over the world including the US [PDF] have had this vision and promoted it via their agents. As I have posted quite a few times before, I don't think one identity for everything will ever work but I am all about reaching a happy middle between the current situation and that Orwellian hell.

Business case for federated authentication

The first comment on the Schneier post on federated authentication is "There is no problem here that people need solved. Linking all these iDs only serves corporations and the government". This is simply not true, increased use of federated authentication would provide significant benefits to users in terms of convenience and security. Convenience in not having to register, setup and maintain profiles for every new service and not having to remember the current plethora of usernames and passwords. Security is also improved because a limited number accounts are easier to authenticate strongly and access is a lot easier to revoke if credentials are every compromised. While some would argue these problems are effectively solved for most ordinary users via the remember me option in browsers or via a password manager. However these are a band-aids for the symptoms not a treatment for the root cause.

Where I do agree with the comment above, is that federated authentication certainly serves corporations and the government; so much so that it is hard to believe that it is not more widespread. These benefits can be considered from a B2C and B2B perspectives. B2C: A 2007 study by Future now found that over 50% of top online retailers required customers to register before checkout. One would hope this has improved by 2011 but a Forrester study in 2008 identified that 25% of potential customers would leave the site without purchase if asked to register. These type of numbers make it seem obvious that if you need any form of registration or signup, make this as easy as possible for the user as it directly affects your bottom line. With federated authentication users can in one or two clicks use an existing identity, no forms to fill, no profile to complete, simples!

B2B: growing your business is increasingly creating a mash-up of services and with SAAS services getting cheaper and more ubiquitous, they continue to grow in popularity.  Jim Scully and Barbara Levin found in a 2010 study for Employment Relations Today that more companies implemented shared services in the two years to 2009-2010 than in the last 15. Any time one company needs to use another companies resources for non public services or information there is an identity and access management problem to solve. This adds cost and time to any project to work out provisioning, approvals, resets and un-locks, and recertification. If part of the business case for using a SAAS solution for something like time-sheets or  HR is speed and cost to implement, it hardly makes sense to weigh it down with yet another access control process. There is also an on-going maintenance cost that increases the total cost of ownership, for example in 2005 Forrester reported that 25-40% of helpdesk calls are password related. With federated authentication, all those problems are already handled by the users existing identity provider.

Barriers to implementation

With so many easy to identify benefits, why has federated authentication had such slow adoption? Security concerns are no doubt a major reason. Trusting another organization to be an identity provider to your resources and in reverse exposing the crown jewels that are your directory services, is a bridge too far for most organizations. These are a valid concerns, however practically anytime you allow another organization access, you are trusting their processes and the contractual measures in place. This includes their staff vetting, their physical access controls and their joiners, leavers, movers processes. Especially where permanent access is required, is it really that different to trusting their identity and authentication systems? In fact where they make take days or months to tell you when staff have left, there is a greater likelihood with federated access than this process is synchronized with their own systems.

Another valid concern is the keys to the kingdom problem. This also applies to password managers, but securing a small number of identity and authentication systems is a lot easier and more effective than having hundreds of weak passwords (or the same weak password a hundred times). Open-ID providers like Google now offer two factor authentication; if you do not like a soft token on your phone, Yubikey USB hardware tokens are also supported by many Open-ID providers. Control and auditing is also greatly improved; do you know every application where you have used a password? Me neither. Yet many Open-ID providers have all the sites where you have granted access to that identity, revoking access is a one click process.

The difficulty or perceived difficulty of establishing a federated identity infrastructure is also often a barrier. No single project wants to take the risk and cost of implementing the required technology and processes for the corporation and security departments struggle to get funding and priority for these projects. Microsoft really missed a trick with not making a version of Windows where all forests had a simple discover and federate option. They were probably too scared of the security and privacy outcry that would have no doubt followed in their hayday to ever try it. Active Directory Federation Services (ADFS) especially version 2 is a great step forward and Windows 2008 provides read only domain controllers for securing directory servers in DMZ's. However it is still not a simple process, requiring each company that wants to federate to setup trusts and manually exchange configuration materials. A fair amount of testing is still required and it is certainly not something business users can setup without IT. To their credit Ping Identity and OpenSSO have also made the process about as simple as it can be. OpenSSO (now OpenAM supported by Forgerock) provides a simple servelet, an agent that can be installed on any web server, configured to use an LDAP and you are ready for federated authentication and single sign-on.

Tipping point

There are a number of reasons that I think federated identity and authentication has reached or is nearing a tipping point. Firstly technologies such as Open-ID, oAuth v2, SAML are now mature and have robust and simple implementations. There are plenty of Open-ID providers with at least one vendor that everyone on the Internet has an account with for products they actually want to use; federated authentication capability is just a nice fringe benefit. Open-ID can be implemented with a great UI that is intuitive even for non-technical users. The Stack Exchange login and I would hope Simple Security Risk Assessment (SSRA) (shameless plug) are good examples. As more and more services move to the cloud, shedding their legacy applications and their password databases,  it will become easier to use federated authentication.  For example Amazon AWS offers an Identity and Access Management service and I would not be surprised if this offered the option of federated access at least across AWS in future. Anyone using Google App's benefits from being able to collaborate with other businesses simply by entering an email address - this is how easy it should be to setup federated access, it should be business driven rather than requiring a technology project.

For new companies it is a no brainer to use an existing identity provider. As a straw-poll consider the latest of batch of Y-combinator recruits millionaires:

  • Convore - Real-time group conversations. Chat with public and private groups on the Web, or the iPhone app IRC for everyone - Twitter and Facebook login
  • Tutorspree - Airbnb for tutoring - Facebook login
  • Earbits Radio - Internet radio that serves as a marketing platform for music-related products. Labels, artists and live music promoters bid for airtime. Shortcut description: “The Google AdWords for the music industry.” - Facebook login
You get the point. Also notice the elephant in the room and our favorite CIA agent yet to be mentioned: Facebook. Unfortunately they are not an Open-ID provider but they do support something similar, for user and businesses there are few practical differences in use. Facebook also highlights a key business reason for federation: access to all that social data and possibility of going viral. More attractive than cost reductions and time savings, this is a real revenue side reason to use federated access. Listening to a startup pitch from Recip.ly at a recent Silicon roundabout meeting, "of course we use Facebook connect so we already know what they like". While this makes the privacy and security side of me cringe if you want to sell federated authentication maybe start with your marketing department. 

Summary

  • The business case for federated access is based on making it easier for consumers to sign-up and use your services and cheaper and faster to integrate with business partners
  • Security and implementation costs are often barriers however these can be overcome with strong authentication for a limited number of identities and via technologies such as OpenAM
  • The tipping point for federated authentication is here, if you want to get in front of the curve Open-ID is well worth implementing 


Like this post? Get updates via RSS or follow me on Twitter @rakkhis


Photo credit: KatB Photography Flikr

No comments:

Post a Comment

Author

Written by