Clayton Donley's Blog

I was reading the comments area on Dave Kearn's recent article about the two-billion user benchmark executed against Oracle Internet Directory and thought I'd answer a few questions and make a few key points.

First, why would we even bother to benchmark a single server to handle such an "unrealistic" number of users in the first place?

The answer is that we get asked to do benchmarks in the 150m range all-the-time and have many customers in telecommunications, online gaming, and online services that easily exceed 50-100m user entries. Rather than continue to do these benchmarks one-at-a-time, it's simply more efficient to prove out that we can blow the doors off just about any number presented.

Don't need 2 billion users? The test shows linear scalability. Get yourself a lower-end box and you're good to go. The exact calculations are very well defined. Can't figure it out for yourself? Send me an email and I'll get someone to do the math for you.

Second, there's a continuing perception that directories are still the read-optimized, hierarchical, specialized data stores that they were 10-15 years ago when the main application for directories was white pages.

I'll be talking about this "need a specialized database" myth in my next post.

Technorati Tags: LDAP, directory

Pop Quiz: Which of the following pieces of data don't belong in a directory server?

A. Username

B. Telephone Number

C. Favorite Color

D. Last Login Time

If you said the answer was D, you've probably read a few good LDAP books from the 90's, when directories were all about white pages and "tuned for reads". This was the same period of time when Java was mostly about applets, if you'll recall (though I still see the old "Java is Slow" myth floating around).

Yes, directories are still used for white pages, but nobody buys them for that anymore.

The real value in directories is the ability to build powerful, user-aware enterprise applications that can share a single source for information about user identity. This means that while directories continue to need to be strong at fetching information quickly, there's also a need to be more flexible and less arbitrary about the kind of information that is stored in a directory.

Last login time, like bad password count and other attributes, is very useful to applications, but violates ancient, arbitrarily establish rules for what gets stored in a directory server (reads vs. writes).

So what does this have to do with read vs. write, flat vs. hierarchical, relational vs. embedded, etc...?

A big ding against Oracle Internet Directory back in the early days was that we used Oracle Database under the covers to store our data. The myth was that this was somehow going to underperform with reads and over-perform with writes (eh? over-performing?). Clearly with the recently posted benchmark, the underperform-with-read argument has been buried and attributes that require writes on login, presence, or location can be easily supported.

A second ding was that because directories were hierarchical, you needed an embedded data store in order to represent that hierarchy. I'd like someone to explain why B-Trees are so much more efficient than R-Trees at this kind of thing -- they're not. At the end of the day, nearly every directory represents the distinguished name as a single, normalized string and indexes it. Your performance is likely to be the same either way.

Now that we've moved well beyond the white pages phase, we need to start treating identity information with the same seriousness that we treat transactional information. This includes layering on real data-level security, secure backups, and performance tuning/monitoring. This is the benefit that Oracle Internet Directory provides.

Technorati Tags: directory, identity management, LDAP

Dave Kearns had posted this article earlier in March and there's been a number of follow-ups (including my favorite here). I sent him a quick note as part of a follow-up on it at the time, but thought I'd share the same with everyone.

1. Meta-directory really merged into the basic directory services layer and stopped being an independent category several years ago, with the exception of one noted vendor. Meta-directories were being used for provisioning before provisioning became process-centric with workflow and identity auditing requirements. Our product direction on provisioning is certainly focused on the next frontier -- seamless integration with enterprise applications, including separation of duties and role management.

2. Virtual directories are really a more application-centric technology that solves the problem of getting the right identities to the right applications in the right format. It's the difference between transforming existing data vs. building new identity stores. Most customers need both provisioning and virtualization technologies. This is probably why so many Microsoft Active Directory users are using Oracle Virtual Directory, given their admitted gap in this area.

Technorati Tags: meta-directory, virtual directory

I spend about 2 hours every Saturday morning at a Starbucks in Cupertino waiting for my 5-year-old to finish Chinese language lessons.

The great thing about free time, Internet, a cup of coffee, and close proximity to Apple is that it gives you time and inspiration to play with interesting software. Lately for me, this has been the iPhone SDK.

Since a few of the teams I manage are responsible for Oracle Internet Directory and Oracle Virtual Directory, it only seems logical that one of the first things I did was write some code that can talk to these products natively. It took about 2 hours from start to finish, including getting an LDAP SDK working on Mac OS X w/ an ARM processor.

Above is a few pictures of a simple LDAP phonebook client that I wrote using the SDK over my last few visits. The pics show it connecting to Oracle's corporate directory with a few buttons for dialing or emailing the resulting contact.

Certainly this is pretty straight-forward and there's a lot more innovative uses of identity information in a device like this. No immediate plans to release this particular tool, but I'd love to talk to other developers that are looking to do innovative things with identity information on mobile platforms, be it iPhone, Nokia/Symbian, or others...

Clayton

I'll be at RSA Security Conference next week (4/8-4/9). Drop me an email or ping me on twitter if you'll be there and want to meet up.

Technorati Tags: iPhone, LDAP

We got a lot of response to our benchmark on the Web and in our email bag. The responses were by the press, customers, and (most vocally) our competitors.

Regardless of where the responses came in from, the one thing that was obvious: people were excited. Certainly nobody was asking if directories were dead, that's for sure. Dave Kearns actually commented specifically about how infrequently he sees things like this in directory.

Not surprisingly, the customer camp loved this benchmark, as it confirms what they have already known and experienced, while giving them a fairly specific set of instructions to duplicate this type of result. It also goes hand in hand with our investment in virtual directory technology to show them that we're serious about having the best-in-breed product in this space.

In fact, the report was SO detailed and complete that it was obvious that the competition was going to try to find ways to discredit the big picture by focusing on the minute details. Since we made no attempt to compare apples to oranges or obscure the way testing was done, we're absolutely confident that this is not only a very valid benchmark, but one that has been more scrutinized than any before it.

Now to address the complaints from the competition. These fell into basically 3 major categories:

1. This is too many entries. Nobody needs this many!

I addressed this to some degree in my original blog post on the topic. This is just something our high-end customers want.

2. This isn't enough entries. We can do more!

I found this interesting, particularly because of who was most vocal about it: Howard Chu from Symas. I find this interesting because a benchmark I'm always asked to comment on is this one, which he did against Sun.

So basically on a system with 8 cores and 16GB of memory in that benchmark was able to scale to 10m entries with some reasonable performance. Now I see that this report is from 2006, but there's nothing newer posted on their site. Specifically, nothing with great detail about a 5 billion user benchmark on a quad processor server. Their own 2006 report also shows that the server isn't exactly scaling in a very linear way as you add entries. If you look at our previous benchmarks, this is absolutely the case with OID.

Another note is that there's no indication in his University of Michigan mailing list posting about the size of entries or other factors in his benchmark. For example, the entry sizes in one of our earlier 100m benchmarks (also published in great detail) was 120 attributes. A lot of scale is very dependent on I/O and clearly a small entry is easier to scale than a large one.

That said, the key point being made with our benchmark was not that someone else couldn't do a bigger one, but that we could do it without making the wrong kind of trade-offs. We're the only directory that can scale into the billions while still taking advantage of key enterprise data management features, such as secure backups, transparent data encryption, database vault, and other things that come with building on mature data management technology.

In fact, the idea that Oracle Database doesn't scale is pretty funny in itself. While LDAP benchmarks are completely unstandardized and generally use some tools built by Sun (SLAMD, for example), database benchmarking is very standardized and Oracle Database is a clear leader in this area, not only in scalability, but price per TPC-C.

3. The benchmark isn't realistic enough

Jonathan Gershater from Sun's directory team has a very thoughtful blog posting about our results. Not quite as dramatic and feisty as Howard Chu, but certainly equally skeptical.

He basically has three points to make:

1. Turning off change logs helped our results

Yes, we did, but this is actually a best practice for most directories during data load, as you'd simply load the initial set on each of the main servers and then turn on replication rather than load the entries in replicas via LDAP replication. Changelog was disabled more to avoid a large accumulation of changes during the various repeated runs, but it may have helped incrementally in the 'modify' tests only.

2. Password policy disabled helped our results

Not quite. Password policy being disabled helped bulkload incrementally, no impact on any other LDAP operation result since only failed bind/compare operations and password updates take an incremental hit. These were turned off primarily to make sure we could use the entries being generated by the Sun benchmarking tool.

3. The queries generated weren't realistic

I disagree. In a 2 billion user environment, you're generally talking about groups of active users and groups of less active users (and even some inactive users). A better test would have been to make 10% of these requests completely random, which I understand a new SLAMD beta is able to generate.

Even then, if one were to cut the number of responses in half in order to make every single user truly random, the results remain outstanding with hundreds of millions of operations every hour.

In Summary

The benchmark is out there. It's a valid benchmark. Certainly people are going to do their own benchmarks and competitors will always find a flaw in any benchmark. If there's one thing we're looking to do, it's publish some of the typical benchmarks we do on every-day hardware as part of each release. And we're going to continue to do it in an above-board way with specific details as we did with this report in order to help our customers size and scale this software in the best possible way.

Technorati Tags: directory, identity management, LDAP

I was reading this posting from my friend and colleague, Phil Hunt, in which he talks about the ongoing discussion between Dave Kearns and Kim Cameron about the death of meta-directories.

Not only is he correct in pointing out that Kim's definition of Meta 2.0 is exactly what virtual directory has been since 1.0, but it's interesting to see that some virtual directory vendors continue to push something that looks very much like meta-directory 1.0.

This something is persistent cache and is a code word for a locally stored meta-verse, which is basically contains a roll-up of all the remote data. I can assure you that Kim Cameron knows exactly what a meta-verse is...he probably invented it at Zoom-it.

Regardless of whether you call it a meta-verse or a persistent cache, the same mechanics apply. You're in the business of synchronizing data between repositories, with all he problems that arise from that.

Glad Microsoft now realizes that virtual directory (or as they call it, meta-direcory 2.0) is the way to go. Wish we could all agree on some standard terminology for these kinds of things, though. It would really help the customers.

Technorati Tags: meta-directory, virtual directory

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

AmTrust Bank packed the room at Oracle OpenWorld, but thankfully the web's a little larger and has more comfortable chairs.

There will be a Webcast on May 1st at 1pm EDT (10am PDT) that reprises the original session and includes some new material.

Follow this link to register for the webcast, which includes K.P. Singh and Peter Dinin of AmTrust and Forest Yin of Oracle talking about centralizing database accounts using the Oracle Database's Enterprise User Security (EUS) functionality together with Oracle Identity Management.

Technorati Tags:
directory, identity management, LDAP, security

Dave continues in his latest posting...

It does seem that when a bold thought is made as an pithy, somewhat humorous statement that it's seen as some how denigrating the subject. so let me say it once again -

Like COBOL, LDAP is so deeply ingrained in our computing arsenal that it can never be entirely replaced.

Exactly. Glad we're all in violent agreement.

That said, the one thing that will be similar to COBOL is that people will be touching it without knowing it.

Just as today there are countless web services that provide access to data that was once tucked away on proprietary mainframes, tomorrow's identity applications will be touching identity data accessed via LDAP under the covers. And just like in the mainframe situation, these directories will only be playing a part of the role necessary to complete the full transaction.

For the record, my first paid technology job (an unpaid internship, now that I think of it) was updating COBOL code on an HP/3000 mini-computer in the late 80's. I can only hope that my code isn't still running someone's business!

Technorati Tags: directory, LDAP

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 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...).

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. :-)

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.

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. :-)

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