Interesting things about ECM


Oracle UCM – Security model, ACLs and performance

Filed under: Oracle UCM, Security, Stellent — Tags: , , — Anthony Fast @ 6:26 am


Maybe somebody should revise the Oracle® Universal Content Management guide, “Managing Security and User Access,” where it says on page 7-4: “If you enable accounts and use them, you cannot disable them without losing data. DO NOT enable accounts unless you are certain that you want to use them.” Either the documentation is wrong, or you lose data. It says nothing about the “appearance” of having lost data.

Page 3-3 of the same piece of documentation says: “The number of security groups should be kept at a minimum to provide optimum search performance and user administration performance. If your security model requires more than 50 security classifications, you should enable accounts and use them to control user permissions.” I take this to mean that the performance degrades noticeably (or can degrade noticeably) after you scale beyond 50 security classifications. Later, the documentation cites an example where changing a single permission can take 10 seconds. Not to be a pain in the ass, Bex, but how does this support your statement “This model scales very well”?? (I take it back. I am being a pain in the ass.)

One last carp. You say that “ACLs are horribly slow and impossible to administer.” For this particular CMS application, that may be true, I don’t know. All I know is that ACLs are the de facto industry standard way of doing this sort of thing. When you choose Door No. 3 and invent a nonstandard approach to solving a problem for which the wheel has already been invented, you only end up needlessly confusing and scaring analysts — and making customers read documentation, something they hate doing.

At any rate, I did learn a lot from your excellent writeup. Thanks for doing it. I feel better now. 😉

Answer by bex:

Don’t know why that’s there… the content you checked in is still in the repository, and the metadata is still safe and sound in the database. Users will lose access to these documents, until you either update all your users, or update all of the values for “account” in the database to blank. You can do batch metadata changes with the Archiver tool… which should be done prior to turning off accounts anyway.

I take this to mean that the performance degrades noticeably (or can degrade noticeably) after you scale beyond 50 security classifications.

In general, performance degradation is due to the complexity of the security model, and not the number of groups or accounts. For example, if you have 100 classifications, but most users can only access one or two classifications, you won’t see many problems. The “security clause” I mentioned above would be pretty small… However, if every user gets access to 50 classifications in different ways, then you’re likely to see performance to degrade a bit because of the increased complexity of the SQL in the security clauses. This can be fixed with some database tuning, however. Some of the admin applets — like User Admin — load more slowly depending on the number of security groups, but that’s rarely a big deal.

All I know is that ACLs are the de facto industry standard way of doing this sort of thing.

Slow searches are also the de facto industry standard 😉

ACLs are easy, which is why everybody does it that way. We took a look at how everybody else did it, and knew that they were doing it in a way that would require a ton of hardware in order to function, a ton of maintenance, and a ton of risk. We didn’t want to go that route… and what we came up with was pretty close to how LDAP does things. Seems to me like a good gamble that paid off…

I cannot name names, but I encourage you to talk with enterprise architects in industries with serious security concerns — like financial and government — to ask them what they think of ACLs in general. As I said, you still can do ACLs with Oracle UCM, but you’ll need beefier hardware.


SQL injection vulnerability for Oracle UCM (Stellent) 7.5 and prior

Filed under: Oracle UCM, Vulnerability — Tags: , , — Anthony Fast @ 1:46 pm



Second finding in Metalink was an exploit in the CMS from Stellent (aka Oracle Universal Content Management), aquired by Oracle in 2007. Publishing exploits with customer URLs is a bad style…


Note 733017.1  from October 2008 says:
Version 6.2 of the Content Server has an SQL injection vulnerability.

Oracle was so nice to publish the exploit pointing to a customer site.

Scurity consultant report states:

Severity: 5
Port: 80
Name: SQL injection
Description: “An SQL injection vulnerability was identified in the following page:****&dID=1%20and%20convert

The back-end version return was ‘Microsoft SQL Server 2000 -8′</blockquote>”

– Business Impact:
Potential security threat

This is a known bug/issue with 7.5 and prior. (internal bug p51038621)


Good to know that SQL Injection is just a potential security threat…

Oracle removed note 733017.1 from Metalink.

Create a free website or blog at