Clayton Donley's Blog

If you had any doubts about Oracle as a player in the identity management space, this short article from Jon Oltsik on CNET summarizes the situation.

Once again, common wisdom was completely wrong. While others struggle or abandon this space, Oracle has vaulted to a leadership position. In fact, my sources tell me they see Oracle in every large deal these days.

I'll let you read the rest for his summary of how why this is the case...

Technorati Tags: identity management

Finally getting around to participating in the latest stream of blog postings following up the "meta-directory is dead" and "daddy, does Active Directory grow on trees?" discussions...

Nishant has already addressed some of these comments in his post from July 16. Mark has hit on other items in his post on the same day.

Now you just have to wait until Ian boils this down to a single sentence again and Dave Kearns finds me secretly agreeing with Kim Cameron on something and the discussion will have come full circle. :-)

James McGovern - July 13

James wants to know 5 things (paraphrasing and with my replies embedded):

1. Why shouldn't we all just put our identity eggs in Microsoft's basket since everyone already has some Microsoft?

[CLAYTON] If you consider that most companies also have Oracle databases and most of the information you'll be needing for fine grain entitlements (meaning the stuff beyond username/password) is stored there, shouldn't this question be why you're not putting your eggs in an Oracle basket?

[CLAYTON] Or better, yet, most of you are using some form of Oracle application (HR? CRM?) to master things like reporting structures, department-based groups, cost centers, who's purchased what product, and so forth. If we're going to pick de-facto standards based on existing deployments, why stop at the directory niche? This information is all coming online with web services and ultimately via identity services.

[CLAYTON] I'm using these examples to demonstrate that very little reusable enterprise information outside of username, email, and some groups are mastered in Active Directory. Sure, some people do use it for more, but it can't be counted on...

2. Are current provisioning products too dependent on central sources?

[CLAYTON] Not to my knowledge. I think it's the opposite. They assume that you don't have a central source...at least ours does.

3. Should virtual directory technology be embedded in new software or stand-alone?

[CLAYTON] We're doing both. We know that nobody will rewrite the old stuff, which needs to work in new identity environments. We also know that some vendors will just never get identity. On the other hand, with Oracle products the push is definitely to at least include a base level of virtualization to improve open-ness.

4. The ideal solution is for people to just write better apps and avoid using virtual directory.

[CLAYTON] Agree. I'd like my car to stop using gas, too. :-) Until that date when every app gets there, we've got virtual directory. We'll continue to publish our own best practices and tools via Liberty Alliance's IGF project and enable our own applications to take advantage of mixed environments.

5. Why aren't more people talking about CARML?

[CLAYTON] There's not been the kind of controversy that sometimes keeps things in the headlines. Quiet progress, if you will. VERY good and impressive progress, though. I think you'll start hearing more about this, though hard to tell if some of the more system-management focused vendors you mentioned will be at the forefront here. After all, most of them don't even have (or understand) virtual directory yet...

Jackson Shaw - July 15

I'll visit some of Jackson's other comments in another post, but wanted to address this part, which goes with James' question #5 above:

What's CARML? Can someone explain it to me? Certainly, until Gartner says it's important I won't be thinking about it... ;)

I'm very glad that Jackson puts his full and total faith in Gartner, because as we all know, the latest Identity Management Magic Quadrants look something like this:

Oracle -> Leader

Everyone Else -> Not So Much

Forester is pretty much in the same boat. So I guess you can all just make those checks payable to Oracle. :-) Joking aside, while I love a nice roll up, especially when they're in my favor, the truth is that things aren't always what they seem.

As I said, I'll drill into his specific comments in my next post.

Jeff Bohren - July 21

I'm in pretty awesome agreement with Jeff that the problem is in the apps that are out there today being account-centric vs. identity centric. Not to mention his experience with Active Directory deployments:

To answer the rhetorical question, the vast majority of AD deployments are not intended as identity stores (at least from my experience). In most enterprises AD is used to manage and control user access to Windows workstations, the intranet, email, and enterprise web applications. AD is not usually intended as a central repository of identity, although it often becomes that with varying degrees of success.

Of course, the hard question is how do you solve it, eh?

A few commendable vendors such as SAP support SAML, but it’s a very small list. Support for external identity services or other identity standards such as SPML and XACML is nearly non-existent.

Wow. Those are the most glowing words I've ever heard about SAP's efforts in the identity realm -- ever. Certainly not the kind of words I'm used to hearing from analysts. :-)

SPML certainly isn't a cure-all. XACML helps and we've got a strong product and even better strategy in this area, but it comes down to application adoption. This is certainly why we're building key integration with fine grain authorization into the platform stack as much as in stand-alone products.

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

You can read the 18+ blog postings covering all of the recent discussions about how dead or not-dead meta-directories really are.

Or, you can read Ian's post that summarizes this whole discussion and save those three hours to line-wait for your iPhone 3G.

As for his conclusions:

1. Use the right tool for the job - Sure. Hard to argue with that.

2. There's room for provisioning, meta-directory, virtual directories, and directories - Sure, all the tools are available, but if you look at most meta-directories, the trend is still to try to make them more like provisioning tools. Not sure why you wouldn't just pick a tool that's already where you want to be.

3. Go with a service oriented approach - Our strategy here is certainly to be more application centric vs. more system management vendors and I think that's shown well when it comes to tie-ins with SOA and serices in general.

4. Meta-directories aren't dead, they're evolving - I agree, but see them evolving more into provisioning tools than virtual directories. This is already happening. I like to think that meta-directories aren't dead in the same way Monty Python's black knight isn't dead, but the reality is that they're trying to get where we already are. :-)

Dan Norris just gave me a heads up on Twitter that Peter O'Brien from Oracle in Ireland posted a short "how-to" for running the OID Directory Manager client on a machine that doesn't have a full copy of OID (e.g. your laptop).

Get it here.

Still picking my jaw up off the floor from this comment from Alex @ the ApacheDS project on Jeff Bohren's blog.

Seems Dave Kearns noticed it as well. :-)

So for those of you worried that Jeff and I might never agree on anything, you can put your worries to rest. Jeff's response is right on target...

Being that I'm responsible for both our OID and OVD product lines here at Oracle, I see first-hand that our customers are seeking very different things from directories vs. virtual directories.

With directories, it's all about data management. How can I scale and manage a repository that can store all of my identity information with the same kind of security that I get from my transactional data.

With virtual directories, it's much different. It's about lightweight integration, minimizing infrastructure changes, minimizing code changes, reducing project risks, and providing the flexibility that helps make both application deployments and identity management deployments successful.

It's not either-or, it's 100% complimentary.

Oh, and I'm wondering if Alex's comment means that I should be saying I'm sorry to my customers for solving their problems without ApacheDS's forthcoming "real" virtual directory. :-)

Some of the points that Matt Flynn raises in this post were addressed in Nishant's reply. However, I wanted to spend a little time on this part of his post:

... There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. ...

What's more likely: 1. everyone standardizing on Active Directory, or 2. everyone not standardizing on Active Directory.

Requiring Active Directory means everyone needs to be using Active Directory for everything. Using a virtual directory places no such requirements on the customer or application. It actually REDUCES the need to have a single, unlikely, unified standard.

This is the case because virtual directories emulate what applications expect from many existing directories. This means it's less about writing to a "virtual directory" than writing to your favorite directory standard and having the virtual directory emulate that in a view.

Not going to argue that the LAN guys have a lot of Active Directory sitting out there. Some of it is very strategic, other times it's used only for workstation authentication (and often outsourced to the people managing desktop user populations).

But there's also a lot of portals using Sun. Lots of databases and applications (e.g. eBiz Suite) using OID. Many people are even using Novell. Plus, even the topologies being used for Active Directory in a company often aren't predicted well by people writing off-the-shelf enterprise applications.

Simply "move everything to Active Directory" rarely works except in the smallest of organizations that will rely entirely on a Microsoft stack (no Java, no other directories, no non-Microsoft compliant infrastructure). Basically Microsoft lock-in.

This isn't to say that Microsoft can't be your strategic enterprise directory, or even extranet directory. But expecting every application from every vendor (including your legacy applications written before Microsoft even had a directory) to suddenly not just support Active Directory, but YOUR DEPLOYMENT of Active Directory is pretty unlikely. And it's exceptionally unlikely that everyone in the world will do so at that precise time as well. :-)

Customer Example

A simple example from a customer a few years back:

- 100% Microsoft Active Directory
- 100% ADSI-enabled application

Unfortunately:
- Global replication with a nasty replication delay (30 minutes)

This meant that if a user (traders in this case) changed their password, it might not get to all of the domain controllers until 30 minutes later, meaning that the traders would be unable to login to their application.

Clearly this wasn't foreseen by the application developer as a possible issue. The real solution may have been to completely re-architect their Active Directory environment in a different way, but you rarely have that luxury in the middle of a fire-drill.

What did the customer do? They spent a few hours installing Oracle Virtual Directory, configuring it to know about their domain controllers, and basically said that when a password failed, try it on the master. The master only sees these requests in "exceptional" circumstances and the replication delay has no material impact on the user's experience.

This provided time to come up with a more strategic solution to the problem. Having ultimately solved the underlying problem, the customer went on to deploy the product for other purposes (better loadbalancing and failover, etc...).

Back from vacation and finding a whole army of people writing about virtual directory while I'm gone.

Working backwards, I saw the following quote from Jeff Bohren in his entry about vendor independence in response to a few posts from our own Nishant Kaushik:

BTW, having written code that supports multiple LDAP vendors at four different companies and three different programming languages, it’s really not all that difficult. The real power in virtual-directories is the ability to consolidate data from disparate sources, not abstracting the vendor for a single directory.

Having written similar code, I'll agree that some of the basic differences are pretty easy to navigate (differences between attribute names, for example). However, others are much, much more difficult.

Some examples:

• Active Directory returns groups larger than 1000 members in ranges. Other directories don't. This requires significantly different logic.
  
• Authenticating to Active Directory without Kerberos doesn't (or didn't) trigger actual logins, meaning that doing simple binds wouldn't respect bad password counts, etc...
  
• Account lock, account controls, password policies, etc... are completely different between directories
  
• Setting passwords is very different between AD and other directories
  

Now add in issues with using basic LDAP to navigate multi-forest AD environments, mixed-vendor LDAP environments, access to databases and web services, etc... and the requirement that applications would need to hit each of these...

Now you have a picture of why virtual directories are so widely deployed (and they are, though I can't share our numbers here at Oracle).

It's one thing to navigate this complexity in one application with a person like Jeff that has strong LDAP knowledge, but a completely different thing to expect that all of your off-the-shelf and in-house applications will have all of this knowledge and execute every step properly across all of these different kinds of systems.

Virtual directories remove that complexity by putting it at a service level. Change directories? Change a setting. Change applications? Change a setting. Add a web service with real-time data from an external source (perhaps a social network or real-time HR)? Change a setting.

Contrast that with the extra code, application rewrites, infrastructure changes, etc... that need to happen without a virtual directory and you see why Virtual Directory is the right way to go in almost every case.

And we wouldn't be pushing standards, such as the Identity Governance Framework and CARML, which will improve Virtual Directory interoperability, if we weren't fully committed to our customers' desire for standards and minimal vendor lock-in.

So I noticed an odd headline in a news feed from the Chicago Tribune this morning: Neighbors seeing red over man's firetruck The gist is that a man purchased a fire truck on e-bay, built a garage near his suburban home for it, and engineered a solution to bring water from his pool to the rescue in the event of a fire. Note that there are 4 fire stations in the vicinity and a fire hydrant 1,000 feet away from the house. His take:

"When you don't have hydrants, you need water," said Mitchell, 59, who does not claim to be a firefighter. "The peace of mind of having the water made my day."

Quote from the Fire Chief about using this water:

"That's really an option way down on the list," Gallas said. "It's available and if we ever needed it we could use it."

What does this have to do with technology, and in particular, identity?

The number one thing that I've seen delay projects related to identity and directories -- as a customer, consultant, and software provider -- has been the tendency to over-engineer these solutions.

In the case above, the odds of a fire are relatively low. The odds that the personal fire truck will be needed is even lower. The odds that the water in the pool will be needed is lower still. By the time you're done looking at the real risk of this happening, you'll have realized that if you thought this risk was real you probably should have just bought some extra insurance, stopped smoking, and stopped cooking with grease (the later two being two of the most common reasons for residential fires).

Similarly, identity management projects need to be designed around realistic goals. These goals should include the right amount of availability and disaster recovery to deal with real business impact in the same way that business deals with other risks.

My favorite case of this tends to be around customers that present requirements for very sophisticated caching in order to circumvent real or perceived catastrophic disasters (complete loss of network connectivity to data sources, those data sources crashing, etc...).

What this tends to forget is that these underlying data sources are often used by many things. For example, if Active Directory goes down, can my users get to their workstations to login? If not, will they mind the fact that their web application can't login either? Similarly, if the database attached to my ERP system goes down and I can't pull their ERP roles, won't the impact of ERP being down be the element that I should be fixing, given that it will impact my company's overall ability to conduct business?

These are just a few examples. There are many more. Other personal favorites would include project delays and complications caused by over-active schema design and planning processes, connectivity to obscure systems that aren't actually core to the business, solving unrealistic and arbitrary latency "issues", etc...

I've mentioned the caching thing several times. Another popular one there is the idea that identities need to be cached for performance. Let's think about this:

1. Your underlying directory will support thousands of requests per second
2. Any good database supports that same neighborhood of selects per second
3. Most databases, directories, and web services have ways of being made highly available if they contain important data
4. Actions such as termination require rapid removal of privileges
5. There is no standard way of detecting changes (for #4) from arbitrary databases and web services that wouldn't require additional complexity.
6. You're probably using #1 and #2 for other, business critical things

Looking at the above, caching is about like buying a personal fire truck. You're adding a lot of complexity for a problem that may not even exist.

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

• Some Thoughts on Facebook Connect, Google Friend Connect and MySpace Data Availability
  (tags: identity socialnetworking)
• blog.pmarca.com: Friend Connect, Open Social, Ning, and the web
  (tags: socialnetworking)
• The Tao of XDI: Did Info Card help?
  Apparently Kim Cameron's integration with InfoCards is keeping poor Andy Dale from authenticating and thus providing his feedback on the latest distributed identity access discussion... I think the answer to his rhetorical question was no, but maybe he en
  (tags: identity infocards)
• Shops secretly track customers via mobile phone - Times Online
  Interesting article. Seems similar to the way that sites track visitors through cookies -- at leas when you ignore the underlying tracking tech.
  (tags: privacy)
• Your Identity in a USB
  Couldn't help but chuckle after coming across this, given Kim Cameron's recent (and excellent) post about the anti-excellence of fingerprints...
  (tags: identity)
• LifeLock CEO Had His Own Identity Stolen Numerous Times, Suit Alleges
  Tip of the day: Don't publish your private information in magazines. Then again, doesn't take a printing press to get your ID stolen.
  (tags: identity privacy)

• Network Security Blog » Data isn't "private" if you put it on a social networking site
  Martin McKeay makes a similar point to mine from earlier. If you register for a service and "ACCEPT" that you're going to share the information in that service, you've given up a degree of privacy to be part of it. This is doubly-true with the case for In
  (tags: identity privacy security)
• Birthing pains in the colonization of the social Web