Social Sign-On – an SSO you can actually L.O.V.E.
Due to dedicating my professional life to information security, I have been discussing and influencing IAM trends now for the better part of a decade. Throughout that time, I have been opposed to openly advocating those three magical letters: SSO, otherwise known as Single Sign-On. I personally did not believe this was any organization’s true goal, but rather a mythical concept evangelized by vendors to promote software resell. Having recently found myself in a number of conversations with customers wanting to know if they can trust Social Media as a form of authentication ("Can we in fact use Social Sign On or the NEW SSO?"), I have had the pleasure of updating my stance in accordance with the advancement of technology and asserting that, as a matter of fact, there are a number of instances where the NEW SSO works very well.
Let’s examine this a bit further. In an earlier blog (July of 2012; Bring your Own Identity) I discussed how many different instances of "ME" there are; I inventoried 22 total (11 work related, and 11 personal). In thinking through this more, I might have misjudged my personal identities by a dozen. For instance, I have unique log-ons to about 10 personal sites that all commonly use my Gmail ID but have separate passwords, or I have manually set them to the same password. This is a nightmare for me to manage, and I’m not the only one having this issue—while writing this blog, a colleague of mine shared with me that he has over 200 entries in his password bank. And I thought I had it bad...
So my own ID management issues and my recent customer conversations got me thinking about how common my user experience is on the personal side. and that I am basically implementing a poor man’s RSO (Reduced Sign-On) already. My first train of thought brought me to ask, "Why aren't more of my personal sites Federated?" I quickly dismissed that knowing my own experiences in trying to help customers complete Federation projects successfully.
But could I benefit from SSO? Let’s take a look...
To benefit from SSO two things have to happen:
- 1) the end user has to benefit by streamlining and easing their end user experience, while...
- 2) the organization can’t comprise security or increase risk to the brand or reputation by allowing this streamlined experience.
Furthermore, to functionally support SSO you must have an initial authentication to some service, and then have a plug-in or integration to share that authentication with additional services attempting to be consumed by the end user.
OK. So every day I log into corporate resources, but I am not going to have the ability to burden my corporate IT organization with integrating log-on plug-ins for sites that I may do business with outside of the corporate world. However, every day I also log into a few social sites and I control that data, and in my opinion it is in those service providers’ best interest to share across those services as much as possible. This is the beginning of Social Sign On, but let’s break SSO down even further:
Consumer sites want to leverage SSO for 2 main reasons:
- 1) they want you to register with and visit their site as easily and frequently as possible;
- 2) they want as much data about you as possible to increase the effectiveness of targeted marketing and selling.
Seems like a match made in heaven, right? I get the seamless experience I want and they get more traffic and better data to drive revenue… so what is the catch?
Control and Risk…
- Control – I own my social credentials and the data about me (or my identity attributes), so in these SSO integrations I need to be more aware of what service provider I am “allowing” to access my data by opting into the integration of my social assets. Simply put, Privacy is a lost art in the digital world but awareness is rapidly taking its place.
- Risk – the risk to the service provider is obviously the level of trust given to that asserted credential (and Identity) vs. the service being consumed. I could likely blog about just this risk for an entire article, so for now let’s just say that the organization has to still consider the risk to the brand if a false identity is asserted and allowed access to a set of services. If you need an example, just look at the instance that occurred this week with Burger King and their Twitter account. So, the more the service provider allows a user to consume, the greater the level of Identity Proofing that should be guaranteed by the Social Site or the Identity Service Provider. Yes - I said ISP. We have officially run out of acronyms.
These ISP’s already come in varying degrees of Proofing, so it is up to the service provider to decide which to integrate with and then subsequently allow you to choose; for instance:
- Facebook, Twitter, Linked-In, Yammer, and others only require a valid email address to consider an Identity "Proofed."
- Amazon Prime requires valid billing information.
- PayPal requires all of the above plus a third component whereby they verify you by interacting with you via a small reported deposit to your banking institution.
Speaking of banking institutions, the example of PayPal as an Identity Provider leads me to wonder why the banking corporations themselves haven’t started to provide your Identity as a service, based on the fact that the majority of banks today still require physical interaction during the establishment of your account.
There are a few vendors, namely Gigya and Janrain who are furiously transforming the internet facing side of businesses today and how they interact with their external end users by leveraging Social Media credentials. Coupling those solutions with adaptive authentication or OTP is why—in the very near future—we will be expanding our online presence, but without having to expand the portfolio of passwords that we have to manage.