I attended this presentation without a lot of practical hands-on knowledge of using OID with either the database or E-Business Suite. Blue Gecko has several SOX-beholden customers, and we plan to implement OID for EBS soon; centralized control for database accounts would also be a huge boon.
Gary is clearly familiar with setting up OID – he was fluid with the material; however, he relied heavily on GUI tools, claiming in some cases it was the “only way” to register database schemas and roles with an OID LDAP tree. If that’s the case, setup could be very cumbersome indeed.
The basic relationship between the database and OID from a user rights perspective is that database schemas and roles map to OID global users and groups, respectively. Effectively, the user is de-coupled from the schema. When a user signs in and authenticates a global user account in OID, privileges and a schema are assigned by OID. If someone has gone around the back door and assigned privileges to the schema unbeknownst to OID, well, that will work too, so an auditing burden certainly exists.
This sounds great – create a global user, then in OID, assign it to various groups that map to schemas (ostensibly with nothing more than a create session privilege) and roles in each database. Trouble is, the roles have to exist in each database. If you want to manage hundreds of database (presumably where OID would add the most value) you need to replicate (and monitor for changes) roles in each database. This sounds like a pain and another (albeit existing) audit risk. I was hoping OID solved this problem.
Regardless, the presentation was delivered well and I’m definitely going to do some more OID research when I get back to Seattle.