An ECM Should Store Content, Not Users

OK, I think I've figured out the disconnect between me and James McGovern regarding SAML... When he asked if Oracle's ECM supported SAML, I was about as puzzled as if he had asked if it supported client connections via JDBC. Well... I suppose you could make that happen, but why not just connect directly to the database? It just made no sense...

Here's why: James has apparently never used Oracle's ECM solution, and is commenting on the poor architecture of other enterprise applications. I believe if he took a peek at chapter 2 of my book, he'd recognize that SAML support is unnecessary in this case... (psst, bug Billy for a free one ;-)

Here's the deal... back in version 3 of the product (we're now at version 10), the dev team saw the emergence of LDAP and Active Directory. We knew it made no sense for an ECM product to be both a user repository and a content repository. That just made things overly complicated. Plus, we could never keep up with the feature requirements. Instead, we recommend integrations that "slave" the content server to an existing user repository.

Put your users in a user repository, put your content in a content repository. It just makes sense.

Here's how a basic request operates: first, the content server asks the external system to authenticate the user's password (or token), and also return a "blob" of info about him. Every user repository has a different API, but this "blob" usually contains group memberships and attributes. The next step is to map the user data to content server specific security groups and security accounts. This mapping can be done in many many ways, from zero configuration to a few dozen lines of custom Java (or C++). Again, depends on the system. Finally, the security check determines if this user is allowed to execute the specific service (like GET_FILE), with the specific document, based on the security groups of the document, the security level of the service, and the user's roles & accounts.

It can get a little more complex with ACLs, personalization, and workflows, but you get the picture.

This happens on the fly: no authorization data is replicated, its only cached for a few minutes for performance reasons. Thus, all user management is where it should be: in the user repository. The content server does a mapping to a content-specific security model, no more.

This is called an External user. People also set up Local users, which are just stored in the database. Local users are discouraged in production systems, thus they are typically only used for testing and superusers. A small handful of customers use exclusively Local users, but they typically don't need, have, or want an enterprise user repository... thus, the only people who could possibly benefit from a SAML interface to Oracle's ECM would never use it.

But what if the Active Directory domain controller is on the other side of the planet, and performance sucks? It appears that some ECM systems make the interesting choice of replicating the user repository... but we'd suggest instead using a product that is explicitly designed to replicate a user repository, and "slave" the content server to that... such as Active Directory Application Mode (ADAM). Some customers went so far as to create home-brewed LDAP spiders to cache data, and then integrate all their apps with the cache.

I feel that making every application on the planet support SAML is a silly duplication of effort... I think its better that applications allow for loose slave-like integrations with dedicated user repositories. Use the right tool for the right job.

Now... SXIP and OpenID? Those are genuinely interesting... I'd bet that people will be willing to pay for an integration with them before they'll pay for SAML. Plenty of clients use SalesForce.com, and might be interested in a cleaner integration between content and customers.

Hopefully this clears things up...