Questions on Authentication, Security, and APEX_PUBLIC_USER

Question

Hello,
I’m evaluating APEX and my DBA’s have some questions about authentication and database connections. I have audit tables in my schema (created using Oracle Designer) and I’ve noticed that APEX_PUBLIC_USER is the user recorded in my created_by and modified_by columns. I’ve read several posts about this expected behavior and its solution - (UPPER(NVL(V('APP_USER'),USER)). See:
Re: User in journal
Re: DB connection by apex_public_user or by registered schema name?
How can I store the user name, not APEX_PUBLIC_USER
I’m ok making the changes in my triggers, but my question is what is the consequence from the DBA’s perspective? If there are 100 users in my application and the DBA’s look at current database connections it will show 100 APEX_PUBLIC_USERs correct? What about any internal Oracle auditing? This is really my first true venture into web style programming. Maybe this is expected behavior.
I also noticed that there are 157 PUBLIC grants to objects in the FLOWS_030000 schema. This means that any DB account has access to these objects by default. Is this a security risk? I would have expected the objects to be granted directly to APEX_PUBLIC_USER. My company is heavily audited in both in an internal and a Sarbanes-Oxley (Sox) sense. This may not be a concern to everyone, but it may be a concern to us. How do other people explain/justify this?
Are we expected to not make DB accounts and only create users inside of APEX? I know APEX supports the DB authentication, but I haven’t seen any definitive “best practice” recommendations on this. I have looked at all the documentation here:
http://download-west.oracle.com/docs/cd/B32472_01/doc/nav/portal_booklist.htm
Is there more documentation with a better explanation than this?
Can anyone explain how APEX_PUBLIC_USER has no direct privilege on tables in my schema, yet it is the user recorded for DML changes?
I know this is alot of questions; we're just trying to get a better understanding of APEX before we make the commitment to begin using it.
Thanks for the help.
Message was edited by:
jabolen

Answer 1

This FLOWS_xxxxxx schema has enough privilege to do DML in my schema (probably why FLOWS_xxxxxx is locked). Is that about right?
Sort of. It has privilege to dynamically execute your DML (and other code) using your schema, so it is your schema that parses the code. (search: sys.dbms_sys_sql)
...enterprise-level identity management solutions...Is one example of that creating DB accounts? I assume others are SSO, LDAP, etc. Where can I read about the pro’s and con’s of these choices?
Good topic for another thread: Best tools for managing user populations (tens, hundreds, thousands, internal company vs. internet/public, etc.) One key factor is who's going to do the work and how does that fit with your business, e.g., user forgets password -> user calls help desk (24/7?) -> help desk accesses admin account and resets password...Will help desk admin use EM, Application Express admin app, SQL*Plus, OID admin, ...?
About authorization and roles, be aware that roles are useful in an Application Express environment only if you have a database user account for each application user (presumably named the same as the account the application user uses to authenticate, regardless of how the username/password lookup is performed, i.e., using the database account's password, LDAP, or something else) and your authorization code has enough privileges to check the current user's default roles, again the roles assigned to the database user account that corresponds to the application user name. This precludes the use of dynamically enabled roles. It also requires your application parsing schema to be able to access global views like dba_tab_privs. So, IMO, it's not the most streamlined approach unless you already have (or don't mind maintaining) a database user account for every named application user, a provision that may be unnecessary to support your authentication (vs.authorization) requirements.
About ref cursors, there wouldn't be any privileges problems - your application's parsing schema must have the privilege to execute whatever definer's rights packages are to be called and these packages, as you said, would do the DML.. As to other issues involving the use of ref cursors, we'd need to know more about your approach and how you want to define reports. I suggest you build a small prototype app and try it out.
Scott