Social networking needs identity delegation strategies

Ever since Facebook opened its platform to outside developers, thousands of applications have been built on top of Facebook. Some have tens of thousands of users and have become part of the everyday experience for many Facebook customers. The viral nature of Facebook means that well designed applications spread like wildfire.

Many of these applications ask users to enter their credentials for some other service so that they can provide a Facebook interface. Unfortunately, users are all too willing to do that if the application offers even a small benefit. Often these applications use the user's credentials to find the email addresses for the user's associates in the service and invites them to start using it.

Suppose, for example, that someone wrote a PeopleSoft application for Facebook (maybe someone already has) that worked through user credentials. When you set it up, it asks for your username and password in PeopleSoft and then authenticates as you and starts digging around. You get a nice dashboard widget of your PeopleSoft data on Facebook, the app gets a ton of data.

In an age where more and more organizations are deploying single sign-on solutions across the enterprise this is downright dangerous. The credentials you give might be the key to everything including your 401K account and direct deposit access on the employee portal. Yipes!

You don't think your employees would do this? After all, it's against policy isn't it? Think again. I found in some non-scientific surveying that people don't equate typing their login credentials into a Facebook application with giving them to a co-worker or friend. You may want to clarify that before the trouble starts.

And yet, in the end, allowing mashing up enterprise applications with other systems, even ones outside the firewall, gives organizations competitive advantage. If nothing else, it means you don't have to build everything and your employees get the benefit of seeing data and information the way they want to. You may not ever want them doing that with PeopleSoft, of course, but there are cases where it makes sense.

Not convinced? Let me give you another type of scenario: more and more organizations are going to online paystubs. You access them with your corporate authentication credentials. Suppose an employee's spouse is the one who does the bills. Do you really think that your employees won't share login credentials with their spouse so that they can access the online paystubs? Don't be naive.

Letting employees and customers share access appropriately without giving them incentives to give away the keys to the kingdom requires better ways of delegating access than sharing passwords. Delegation should be an anticipated interaction model in network applications that we design and build. Unfortunately, many organizations are struggling just to get single sign-on working let alone designing a complicated delegation system into everything. Sit down for a minute and try to design a reasonable, easy-to-use, secure delegation pattern for one application and you'll see how complicated this can be. Got an interesting solution to this problem? I'd love to hear it.