Over a million developers have joined DZone.

OpenID, OAuth and the Enterprise

DZone 's Guide to

OpenID, OAuth and the Enterprise

· Web Dev Zone ·
Free Resource

I spent last weekend in Sebastopol, CA at Foo Camp where the topics discussed were around the Social Graph, Privacy, OpenID, OAuth, Data Portability, Intellectual Property Rights and much more. Click here to Google:FooCampSocialGraph2008.

I made some great connections with people there and mostly observed the discussion and thought, and thought, and thought. I want to thank David Recordon, DeWitt Clinton, Jesse Robbins, Joseph Smarr , Tim O'Reilly and many more for all the great conversations that I had and for welcoming me in as one of the very few "enterprise guys" during the weekend.

So now what? I have lots of ideas.

The Social Graph and the Enterprise

Much of the conversation was directly directed at providers and users of consumer-focused applications. Since social networking and variants were heavily represented in all discussions, this was very appropriate. While on the consumer side of the application and social networking world the demand for the convenience of a secure methodology of data sharing between applications makes a lot of sense, there is still a lot of conflict even with the vendors and providers of solutions on what amount of data to share, etc.

The data portability and OpenID communities are quick to label enterprise solutions vendors as "evil" because they feel that this is inconsiderate toward users and their desires to have data portability and freedom to choose.

When I begin to apply these concerns to the enterprise, they are further magnified by some very significant differences that can not be underestimated in the enterprise world. As a provider of applications to businesses who have users in them, I can not simply mandate "We support OpenID when the entity of the user in a company is not mine." A user in a company's account belongs to the company.

Let me explain.

The Business Identity & Transaction

When a representative of a business signs up for an application to be used by a business, they make a representation that they have the necessary authority to do that at some level. Additionally, when they begin to add other users inside that application; the business has administrative rights over the identity of the user inside that application.

We understand that someone may sign up to try a solution who may not be the administrative contact once the application is adopted. In this circumstance, administrative rights are transferred to the necessary party within the business; but this is all possible. The net result is that businesses are identities and businesses own other identities within them.

Let's go to the next level.

Adding Additional Users

With each additional user that gets added within an application owned by a business, their information in the application and their identity (assuming it's a business application like CRM) is traditionally an asset of the company. This includes all data in the system and the very identity of the email address itself.

Now that may be a shocker to many of you who are employees and just now discovered your email address at work is not yours (and not private). Your employer owns it and upon exiting the relationship, it's no longer yours to have. Nor is the data that you entered into the system as an employee yours - it's your employer's. If you thought that the information you type, import, read, etc. is all yours... sorry to bring the bad news here. It's not that your employer is bad, it's just the legal details of ownership of business assets.

Identities as Assets of the Company

The dimension of "ownership of the identity" is where my concern lies. While I openly embrace the concept of OpenID and OAuth and even Data Portability, enabling the transfer, federation, collaboration of the data itself required to improve the users experience is not merely my decision to make. My "identity" in "the company" is not mine alone and all correspondence and collaboration with that "identity" is an "asset" of "the company."

Here is Where it Gets Really Confusing

Currently, what goes on in authentication sharing is more than identity. Unsophisticated models currently allow access to applications and user data can be imported from one application to another. A common example of this is giving access of your web based email service with your username and password to another vendor.

Let's look at a scenario where we enable technologies to share data between applications, where user identities allow for flow between services and/or websites and suppose we integrate more services to enable better data portability between applications (ie. a friends list in a social networking site gets imported into CRM and an Email app's contact list). Here are three issues that cause concern to me at this time:

1- Some users will feel victimized if all of a sudden their information that was automatically imported is now an asset of the company that they work for; inside an application that they are a user in.

2- On the flip side, if I enable data portability "outbound" in an application through automation for the users benefit; I must consider that the "business" that this user works for may feel their rights violated and that their assets were compromised.

3- Dimension number three is the contact on the list itself. As an example, I find that I am appearing in more places because of the phenomenon known as the social graph, and social networking. My name is on some friends lists that keep getting imported, exported, and moved around. What was once a private relationship is now being made a business asset and a replacement contact is assigned to me with whom I have no relationship with. How do I feel about that?

Now What?

So now that you've read all this background of applying these principles to the enterprise. Now what? Implementation is critical to a decision to adopt and protecting users and companies, both. Just opening up without the respect of the appropriate identities is reckless. So I have some more things to consider.

Identity Protection Concerns

The biggest concerns I have when I think about consumer solutions are identity protection and data architecture. Enabling collaboration between applications for most vendors comes with a cost that users don't think about. For example; if you want to synchronize your data between apps and you provide your authentication information, you have just given your un/pw info to that vendor in trust. What will they now do with that trust? Where do they keep that data? How secure is it? What permissions did you just surrender? I am amazed at how many users surrender their identities without second thought about what keys they provided to someone to ruin their lives.

Currently, there are numerous companies on the web have very pathetic security for authentication, and identity risks abound. Having one authentication that grants access to all your applications may sound appealing, but it also means that one key unlocks potentially all your identities. And if a vendor can use your "email" to get access to even more, the security risks to the user and the business who technically owns your identity are extremely significant. As a consumer, it affects you; in a business it potentially can affect the entire company's assets.

Is There a Better Way?

The biggest promise provided in the movement of adopting OpenID and OAuth is that there are better ways to share data in limited fashions that provide the experience the users want, without sacrificing security of the more sensitive information. But simply solving authentication and giving access to all data and to all services doesn't exactly get us there.

The real problem is going to be how vendors use the identities and what data is allowed to flow from one app to another. The hope is that the user gets the experience they want (i.e. data sharing, profile sharing, contact lists - maybe) without surrendering security; (i.e. total email access and control of your email identity).

The apps that are used as the keeper of identity and they need to be made more secure. Apps for communication; like email, have become the source for making sure "you are you." Once these identities are now surrendered, you now are at the mercy of your vendor.

Still More Questions to Ask

I believe that there is tremendous opportunity to improve things if the industry puts new principles in place, and I also think there are more questions to ask before it can effectively be adopted in the enterprise. Do users know that when they import data from a social networking application, their contacts become assets of the company? Do they know their email address is not theirs? And the contents of that email is also an asset of the company? Using an ID that is an asset of the company to work with other consumer oriented sites may also create other risks.

Now granted a lot of these issues effect consumer oriented sites today, because users sign up with their company identity. Regardless of where we are at now, the need is very real to improve how we collaborate and keep information and identities secure.

So What Will Etelos Do?

I can't exactly say what we will do, until we start doing it.

But I believe that the Etelos Marketplace TM is a great place to start supporting OpenID and/or OAuth. Why? Primarily because users can try and buy multiple applications that integrate with other services; essentially having a central ID that launches many other applications.

Enabling this experience to be as easy as possible is a basic principle we can get behind. After the initial user in an application is deployed, it gets a little foggier about how we can best support both the end-users, the businesses/accounts they work for, and the initial business contact that signed up. Additionally, developers that are distributing applications through Etelos need to decide how to support these initiatives as well. We currently do offer an API to federate data from the Etelos Marketplace to the Apps/Services that we sell and install. We are not far from embracing more, and perhaps better, ways to do this.

We have more to say on this; more investigation on this. Odds are that we will communicate with our users here on our blogs about ideas as we pursue them. So check back on our blogs soon for more on how we choose to embrace these new emerging open standards.

Originally posted at OpenID, OAuth and the Enterprise. Used by permission.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}