Clayton Donley's Blog

For those of you that don't like reading press releases and wonder what all he buzz is about our recently announced Service Oriented Security offerings, Tony Baer from OnStrategies has a great roll-up here.

Nishant Kaushik, one of our key architects, does a fantastic job of boiling down this announcement as follows:

SOS covers the four stages of an application lifecycle - development, deployment, administration and governance. With SOS, organizations can now centralize and externalize security solutions as part of a flexible security architecture. Recent identity related efforts like the Identity Governance Framework are also part of this architecture, providing the ability to deliver privacy-aware applications.

Certainly the key take-away for customers and those building everything from the next bank portal to the next Flickr is that you can get cohesive identity management as a service today, so you're better off crafting your value on top of these services rather than trying to do a better job with identity management fundamentals.

I'm in Seattle for my brother's wedding, so was unable to see Thomas' talk at RSA yesterday. I would love to get some email with first-hand accounts and feedback.

Technorati Tags: identity management, LDAP

Wow. Lots of good discussion lately on both the identity services topic as well as general directory services (meta, virtual, and the like).

I'll start with Jeff Bohren's AD as the elephant in the room post.

I agree with Jeff that Active Directory is almost always a source for internal user information. I also agree that LDAP is everywhere (having written a book on LDAP and one of the early Perl interfaces to it along-side Netscape, I MAY be biased on this point).

What I think his post misses is the fact that most LDAP access in most applications is poorly written, even when using ADSI or ADO to talk natively to Active Directory. I can't count the number of virtual directory deployments that we've sold to help customers in environments that were nearly 100% Microsoft (ADO/ADSI-enabled apps talking to Microsoft AD). Many of these deployments were to get around bad schema assumptions, others were to get around topology issues or forest boundary issues.

While we sell virtual directory technology, we hate making our customers pay money to solve such tactical issues. We want to be layering on higher-order value.

So when Phil Hunt or others talk about the Liberty IGF project, what they're really saying is that we want a better way to give application developers a way to code something in a way they understand and can do well rather than a native access protocol that requires specialization. So while LDAP isn't going away and everything from virtual directories to identity buses will need to support native access over LDAP to be successful, not looking at what developers are learning and using every day would be a mistake.

Keep in mind that developers must integrate with a LOT of technologies to build an enterprise application or portal. For example, a portal may be integrating with HR, CRM, and ERP systems. That integration is increasingly happening via web services. Giving these developers a mandate to use a completely different type of technology to integrate identity will only make identity more specialized and less standardized and understood over time. That is a recipe for disaster.

And as for Active Directory itself being the center of the universe? Hardly. While it may be the center for usernames, emails, and passwords of internal users for most enterprises, it is not as popular for extranets and Internet facing users.

As for Kim Cameron's post on second generation meta-directory and the identity bus, he knows better than me what the original ZoomIt product was capable of (and oddly enough, I've heard enough rants in the past from Phil Hunt about how much he loved that product that I'm inclined to agree that it could in fact, do these things).

Here are Kim's three key requirements for an identity bus:

By "next generation application" I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP.

Developers and users need places they can go to query for "core attributes". They must be able to use those attributes to "locate" object metadata. Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.

Applications need to be able to register the information fields they can serve up.

His first point is exactly the same as my point above. LDAP is great. LDAP is ubiquitous. LDAP is not, however, the future of identity access.

On the second point, that place today can be a directory, database, web service, or just about anything else -- and usually more than one of these. The big issue for developers and IT organizations is that it's hard to predict where this data will live by the time an app goes into production, so some abstraction service must exist. I'll disagree with Kim here and say that real virtual directories do an EXCELLENT job at navigating these complexities by giving application developers a sort-of identity dial-tone. Make one call and get your full identity. We even have people who do this over web services rather than web services for some applications, but there needs to be more standardization here.

On the final point, I'll go further. It's a two-way street. Applications need to register their identity needs and repositories need a way to have their available attributes (and policies on those attributes) discoverable. Only then will supply and demand be accurately mapped, allowing services (whether based on IGF or an identity bus model) to thrive.

Technorati Tags:
directory, LDAP, meta-directory, virtual directory

When is a network NOT your network? If you're an typical person working for a typical company, it's when you're talking about SOCIAL NETWORKS.

However, this isn't always as bad as it sounds.

I've spent time over the past several months trying out various social networks to understand how people at a typical enterprise might use them -- other than to get a job outside that enterprise!

My interest was originally to understand how we could do a better job supporting more dynamic networks of employees, partners, and suppliers in meaningful online situations.

After all, many of these users are all represented in your enterprise's existing networks in directories, databases, and applications. If I look for a document in my content management system, doesn't it make sense that a result might come back first as much because of who wrote that document and their relationship to me (reporting, project groups, departments, tags, etc...) as much as because of the proximity of my search terms?

That said, this posting is less about enterprise social networking than it is about the existing social networks that everyone knows about and how they fit for an enterprise user:

LinkedIn

By far the most corporate. Most of the people in my address book have an account here. They generally don't do much with these accounts other than "link", but they're there.

I could see a lot of situations where using technology such as virtual directory to link enterprise directory users with their connections on a service like this might be useful...except that the actual relationships here are ill-defined. I might have added some people that I work with all the time and other people that I haven't talked to in ten years. I may have also added people that I talked to once at last week's conference that I'll never talk to again.

As those of us in the identity and directory spaces have known for a while, figuring out how identities really fit together with all the various other identities (e.g. taking ad-hoc groups of users with the same privileges and lumping them into a role) is a lot harder to do than it sounds.

If there was more context around these relationships, linking to it would be the easy way to give your sales people a roadmap to reaching the person they want at a particular account through someone they already know. Or lets you know which partner might be the best to go into an opportunity with based on their existing successful relationships with a customer.

Clearly there's a lot more here, but given that I'm not actually linked via LinkedIn to most of the people I'm REALLY related to (colleagues, managers, staff, etc...), the network being shown is far from complete.

Facebook

Less corporate, but not Myspace (which I won't bother to mention at this point). Probably 10% of the people in my address book could be found on this service.

If I wasn't linked to anyone I deal with on a regular basis on LinkedIn, this is even more the case with Facebook. One again, while I have a network, it's missing major people.

Even more troubling to adoption in corporate environments, though, is the application platform. There is one, but most of what has been built on it isn't very meaningful and it's hard to find the stuff that might be good or become good with enough support.

Since some of the emphasis here is on content sharing (photos, blogs, comments, etc...), many enterprise users are going to be cautious about inviting their colleagues, managers, or subordinates to their network out of concern that sharing their photos from Tahoe might not be interesting to that class of people in their network.

As a source of data and enterprise network information, I have a hard time seeing where a typical enterprise might want to hook up, even with well documented APIs.

Once again, the key problem here is that the "network" lacks important context and even if manual context is created, it can get old fast. After all, nobody's paycheck is linked to their Facebook profile being up-to-date.

Twitter

Twitter is by far my favorite service. It's had a lot of downtime (hint: move your database to Oracle...:-) ) and of my entire address book only contained one person out of 150+.

Certainly at a hit rate of 1/150, it's a network...but a very, very small subset of my real network.

What's different here is that Twitter is less about recreating your own existing real-world networks on the Internet than it is about getting you to communicate with NEW people about NEW things.

It's funny that I wrote the above, as I signed up for Twitter 6 months ago, only to regard it as the medium for "I'm in a boring meeting" announcements, or any other statement that was too boring to write in email, blogs, instant messages, or so forth... It wasn't until 4 months later that I touched it again.

What changed things was this great article about Twitter by Robert Scoble. Basically, the trick to Twitter is in who you are following, not so much in who is following you (not many will at first). Once you're following good people, you're learning new things and contributing to conversations. If you're interesting enough, people will follow you back (and you'll feel good about that...).

So what does Twitter have to do with the Enterprise?

In actuality, the connections made here are even less likely to be meaningful than with either Facebook or LinkedIn. However, it's more likely that someone that uses the service will actually be producing some level of content and because this content is 140 characters or less, it's likely to be less "controlled" than a typical blog posting.

So as an enterprise, I may not interested in the identity connections, but I do want to see what people are saying.

I use a service called Tweetscan that actually gives me every public message sent with the word ORACLE in it. These messages are short and easy to scan.

Every once in a while I come across a gem like:

Sun Identity Manager does not scale...i've come to the conclusion. I wonder if Oracle Identity Manager does...maybe CA? 02:46 PM April 25, 2008 from web

Do you think I followed up with this happy Sun integrator?

Absolutely!

But I just as often follow up on messages that are less specific to my particular responsibilities. After all, the idea here is not to simply spam your commercial messages -- it's to be a participant in a NEW network of people.

Other Networks and Conclusions

There are many, many other networks. I've joined many of them to get a better idea of what's good and bad about them. Some, like Brightkite show a lot of promise through integration of location-aware features. Others, such as DIGG serve as an interesting model for what enterprise portals could do a better job of: showcasing content that others like me think is interesting.

But generally speaking, if I'm looking at identifying the people closest to me in my enterprise setting, the real world is not likely to be reflected in my online social networks. Some networks get closer than others. With some networks, this doesn't even seem to be the purpose.

There are people for whom this is an exception. Certainly online networks are likely to be more accurate for younger people than older people. They are also likely to be more accurate for people in external facing roles (e.g. standards, marketing, sales), but these people also tend to have larger external networks, so differentiating between strong relationships and casual relationships may be even more difficult due to the lack of strong, up-to-date context.

Certainly here at Oracle and particularly in Identity Management we're paying a lot of attention to what people are doing and the enterprise potential that can be delivered to our customers from existing services, as well as the general models and opportunities that they represent.

Technorati Tags: twitter, facebook, linkedin, enterprise social networking

At about the same time I put together yesterday's blog posting about many of the existing personal social networks, Thomas Kurian, the Oracle SVP responsible for Fusion Middleware (among other things) was giving a presentation at JavaOne related to our own efforts in the area of enterprise social networking.

The key word here is enterprise.

Note in the demonstration that you're seeing orders, people, conversations, and other elements linked together from enterprise systems.

Note that the relationships, tagging, and other functionality didn't require redefining new people and relationships, or re-registering for new services. Relationships in an enterprise are often pre-existing. Customers exist. Employees exist. Partners exist. The relationships are often defined in databases and directories, while deeper context exists and can be brought to the surface through integration with business applications.

As the CNET blog posting above indicates, other companies will say that this has been here all along. What those companies aren't saying or showing is such strong integration with existing enterprise systems. There are no green fields in this demo and that's the reality for most enterprises.

For the identity buffs reading this, note the integration of traditional white pages functionality with presence services, instant messaging, and other elements.

From a directory services standpoint, if your existing applications can query a directory today, using virtual directory automatically extends them to access your presence services, database data, and other non-traditional identity information without needing to adopt new frameworks. This shifts the focus from how do I get the data to how can I use the data. Solving the later question is where the value is achieved.

Really fantastic stuff.

Technorati Tags:
enterprise social networking, virtual directory, JavaOne

Dave Kearns says LDAP is the COBOL of Identity.

Jeff Bohren says it's actually the SNMP of Identity.

So now that we're talking about LDAP's role in the universe...

There's no pressing need to get rid of LDAP in existing applications. None at all. It works. The applications support it and will continue to support it indefinitely.

Even in next-generation application I see LDAP support being integrated -- hardly what I see of COBOL and not as the afterthought that SNMP always seems to be.

What does this say about any future identity services?

They must support LDAP-enabled applications.

Does this mean that they will only support LDAP? No.

Does this mean that we shouldn't move new applications to frameworks like the Identity Governance Framework that make it exponentially easier to build identity-aware applications? No.

It simply means that if you want your existing applications to support your new identity service, it had better support LDAP or most of what you have won't work with it.

That said, movement requires motivation. If LDAP is good enough, we'll be talking about next generation identity services for a dozen years before anything meaningful gets shipped. After all, it was almost a decade ago that Bowstreet and others talked about replacing LDAP with DSML. This went nowhere.

So what great advance would provide this motivation? It won't be security, audit, and compliance. These things can be achieved today with LDAP and strong identity management software. If you can do it today, why rework everything?

What's likely to drive the move from LDAP to identity services is the enablement of new applications that have enormous potential for driving business growth.

An application that can take advantage of the extensive information available around identity in a way that relates that identity to its peers, communication, transactions, and other elements can really contribute to business. Since the full picture of identity and its relationships is much richer than LDAP's information model can describe, we will then need to move beyond the LDAP data model -- not by simply rewriting LDAP in XML, but by redefining what an identity representation for applications should look like.

There are many candidates for next-generation LDAP. Which one will win out? I've got my opinions, but in the end it may not matter.

Why? Because virtual directory technology insulates applications from the underlying changes in technology. This technology will easily adapt to add new listeners and adapters for emerging standards while retaining LDAP for the applications that have been written and will continue to be written to that model.

Technorati Tags: identity management, LDAP, virtual directory

While I may not agree that doing SQL through your virtual directory to get access to combined views of transactions and identity information is the right way to go (and I think Dave really wasn't trying to say that anyway), but...

I absolutely DO agree with Dave (and Vikas Mahajan) that there's no reason we should be building additional infrastructure around moving identity around vs. moving any other data around.

Let's keep in mind that a bus can move any arbitrary object from A to B or even A to B, C, and D.

The trick is to make sure that all of these points understand the object being passed between those points.

Just as multiple LDAP-enabled applications need to understand the same schema, multiple parties publishing/subscribing to a queue will need to understand the same messages.

This is true even though each application may only need a slice of that identity data. The overall structure of what is being shared. The Identity Governance Framework (IGF) actually gives you a standard way of defining the attributes present in a message you could accept/publish. It even provides a place for defining which attributes might be used as keys by your particular application, which helps in the previous discussion re: joins.

If we agreed to use IGF's CARML representation to define the attributes that would be present/required by an application and agree on what representation will be used to encapsulate those attributes, all you need is a standard message bus.

Of course, the question then becomes, who will take the messages off the bus and send updates to legacy applications and who will take updates from legacy applications and push them onto the bus in the first place.

This is where identity services come into play. Like virtual directory, they're simply moving data from one context to another so that everyone else doesn't need to adapt to the legacy environment and legacy environments don't have to adapt to each other.

Maybe I could ask my friend and colleague, Phil Hunt, to spare some time to post a quick example of how this looks in real life.

Technorati Tags: identity bus, identity management, LDAP, virtual directory

So there's been a lot of press in the last few days about Facebook shutting off access from the recently announced Google Connect social platform. For those of you that pay attention to identity management, but haven't paid attention to this particular situation, note the following couple of quotes: Robert Scoble comments:

Facebook is being consistent here. Dave Morin told me a few months ago all about Facebook's concerns. Such as, what happens if you change your email address, will it change everywhere that your email address got copied to?

So when Robert Scoble wrote this evening that Google is in the wrong, I disagree. I think Facebook's intentions aren't to let users get data out of the network until Facebook is absolutely forced to do so, and then only on Facebook's terms (see Facebook Connect). The fact is, this isn't Facebook's data. It's my data. And if I give Google permission to do stuff with it, I'm damned well within my rights to do so. By blocking Google, Facebook has blocked ME. And that, frankly, kind of frustrates me.

Michael is clearly in the user centric identity camp with his comments.

Robert's comments (or rather his agreement with Dave Morin's comments) are very similar to the type of concern your typical IT manager has about moving data between applications...only on a much larger scale.

In an ideal world, your identity is your own and you have granular control over who gets what and where it moves.

In reality, if the average user was presented this question as often as identity was requested, it would be a bit like these "desktop firewalls" that continuously ask you to "accept outbound connection to IP 10.10.10.20". Meaning that you'll grow numb to the requests at some point and simply grow accustomed to clicking "Accept" for every request for that data, knowing that clicking "Deny" means that the program (or service) won't work.

This is actually one of the issues that must be overcome by the user-centric identity crowd. It's one thing to provide a layer of security and control, but another thing to make that meaningful in real life.

On the other hand, assuming a data owner (in this case Facebook) wants to actually share their information with a partner (in this case, Google), Robert's mentioned concern about keeping synchronized copies of the data is valid. What's the solution to this part of the problem (assuming that the real problem here isn't Facebook being concerned about Google cannibalizing their business by building a better widget with their users)?

Seems like a case for some combination of virtualization and federation. What do you think?

UPDATE: Note a slight update on Scoble's blog that clarifies a few key details. Removes some of the synchronization/staleness issue, but interesting never-the-less.

UPDATE2: Google employee Kevin Marks says I'm wrong in comments here. Here's his correction to this post: "Robert, you're wrong about Friend Connect data getting stale. It's fetched directly from your linked Friend Data sources, including other Social Networks, with short-term caching on Friend Connect servers. There is a live two-way connection - Friend Connect posts back events to the Social Networks' activity streams when the user choses to do so."

Technorati Tags: facebook, identity management, privacy, identity

Kim Cameron of Microsoft just reposted a shortened version of his laws of identity.

I really didn't comment much when these were first being developed, though I recall being at a number of forums and conferences where discussion about them took place.

While they've gotten a lot of focus at times, I have my doubts about how important and practical some of the "laws" are. Rather than just parrot the laws, I thought it would be useful to discuss these possible issues and see what others may have found that either mitigates these issues or bring them to focus.

Here are the shortened laws in bold and my take on them:

1. People using computers should be in control of giving out information about themselves, just as they are in the physical world.

There are two ways identity information gets populated and shared:

1. We put it there, or

2. Someone else put it there.

We can all control the first path. I can choose to fill out your web form or not based on whether I will exchange elements of my personal information for the value that you are providing.

For the second path, we use enterprise systems every day where the systems in use have some existing knowledge about us. Marketing databases are bought, built, and sold every day -- often by the same publications that will actively run shrill articles about how your privacy is being invaded at this very moment.

In effect, often times once you've done #1, it's hard to prevent #2. You can give a web site the technical ability to reduce #2 and actively enforce a stricter privacy policy, but the reality is that the Web 2.0 world is often driven by "free" content and services that will drive more, not less, of this collection and sharing.

2. The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

Nothing wrong with this particular ideal.

For example, when I get mailings from third parties as a subscriber to Harvard Business Review or TheStreet.com, they are always sent by those entities, not directly by third parties -- or at least they appear to be.

In general, this is actually a good business practice. Oftentimes the data you're collecting has proprietary business value in itself. If your business has made the decision that you're willing to part with it, you're highly unlikely to worry that there's a law of identity related to this.

You might be a little worried if there is a REAL law related to this. It's not like hospitals can go around selling lists of patients to drug companies. This is where privacy laws come into play.

3. It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

So I guess I should stop using FriendFeed, Facebook, and LinkedIn, eh? :-)

Ok. I know that this isn't what's really being said here. What's really being said is that using a shared identifier across a large number of systems allows people to know things about you that they shouldn't.

True. That said, this is hard to do within an enterprise. Are we really on a path for convergence across the vast Internet?

4. We need choice in terms of who provides our identity information in different contexts.

All of the references to control remind me of how most Windows firewall products work.

Basically I click on an application or link and get a pop up window in the lower right corner of my screen that says something like this:

"Application XYZ is attempting to access the internet to connect to 192.168.1.5 on port 848. Would you like to allow this? YES/NO"

The one thing all users learn quickly is that if they click YES, the application works. If they click NO, it doesn't. After a while, the pop-up is just another annoyance for the user such the actual applications, hosts, and ports aren't even noticed.

Now translate this to most web applications where if I click YES, some amount of information is shared and I can access what I want. If I click NO, nothing is shared, but I can't get access. What do you think the typical user will do? Do users read the EULA and privacy terms before they click?

And keep in mind that if we automate the process of entering all of this information by keeping it on a electronic card, they'll actually notice even less about the information that they're sharing because they won't be entering it. It'll become Yet Another Dialog to Accept (YADA?).

5. The system must be built so we can understand how it works, make rational decisions and protect ourselves.

6. Devices through which we employ identity should offer people the same kinds of identity controls - just as car makers offer similar controls so we can all drive safely.

It's hard to disagree with these last two points. They're very attractive points and give the users a lot of control.

I do like things such as the new Firefox address bar, which actively help me figure out whether I landed where I intended:

I also like the auto-form fill-out functionality in most browsers that makes registering for the myriad of sites easier.

Combined, this lets me know that I'm sharing my information with the entity I think I am and can visibly see and adjust the information I'm willing to share.

What's missing here is user education. A year ago, you had to look at the link you were following and know the structure of a URL to understand that you were being phish'ed...or just not click on anything. Incremental enhancements, such as those in the address bar, give us a path towards training users to avoid these negative situations without requiring them to be geniuses.

After you've verified that the vendor in question isn't fraudulent in itself, the question becomes whether you want to give the information requested.

Portable identity is probably helpful here, but if I were an enterprise I'd be more focused on the back office.

Just as it's a bad waiter that stole your credit card number and not an evil plot by TGI Friday's, it's not the intent of most organizations to actively compromise private information.

The difference here is that instead of a handful of credit card numbers, we're talking about whole repositories of data.

This may be an identity management problem (e.g. user with too much access and not being audited), but it's just as likely to be a data management problem, backup security process problem, or other issues that can lead to massive insider compromise (accidental or intentional). If you're not solving these in a concerted way, it won't matter much what your privacy policy is except for any liability you've created for yourself.

In Summary...

Not saying that the laws of identity lack value in the real world. Not saying that users shouldn't control their destiny.

Am saying that we need to be careful to ensure that these laws line up with the reality of how people use computers and that the embodiment of the laws doesn't open up additional risks, while keeping us from focusing on systematic risks that might be taking place behind the browser in or applications, middleware, databases, directories, and back office systems.

Technorati Tags: identity management, privacy, security