Oracle dbms.set_role does not work in APEX application

Question

in our j2ee applications, we use secure application role. Basically, the data source use the app user schema to connect to the database. the app user only has create session privileges. the database logon trigger will copy a set of attribute to the local secure context. (ip address, session user, client id, application name). The applications explicitly invoke the stored procedure sec_mgr.set_role before any DMLs are executed.

the sec_mgr.set_role will check the local context attribute , authorize the ip, application name, and set an appreciated role to this session based on session user.

we want to apply the same framework to the APEX application. First, we change the paring schema to the app schema which only has create session privilege. then we put the plsql code in which sec_mgr.set_role is called in the application builder --> shared components ---> edit security attribute ---> Virtual Private Database (VPD).

however, we got the error ORA-06565: cannot execute SET ROLE from within stored procedure

the sec_mgr.set_role is defined as invoker's right(AUTHID CURRENT_USER)

do i missing something in APEX to get it work?

Thanks

Answer 1

The problem here is the APEX security model is completely different from the J2EE one.

APEX users are not database users, and don't have access to anything in the database except as defined by APEX security. Database users are not APEX users and the lack the privileges to log into the APEX application.

The database user that runs the APEX application (APEX_PUBLIC_USER or ANONYMOUS) needs to have non-role based access to the schema/tables used by the application itself. Since each page/submit process is (effectively) stateless, every single page view or submit process is trying to run the "SET ROLE", which isn't required.

You can read this discussion or this discussion of the APEX security process to give a better idea of what's going on.

Answer 2

just ran across this while researching another Apex role issue -- Thomas Jones-Low's answer needs a bit of clarification... where-as apex runs as APEX_PUBLIC_USER or ANONYMOUS, that is not what controls database privileges at run time or design time. Each Apex workspaces is mapped to a schema, and the privileges associated with those schemas are used a t runtime and design time -- otherwise all Apex workspaces would have unlimited access to the database, as they all connect as APEX_PUBLIC_USER or ANONYMOUS.