Role Based Access Control (RBAC), Oracle User Management (UMX) and Release 12

There are three dynamics that come together in Release 12 to produce inflection points where increased levels of access may not have adequate enough controls surrounding them. First and foremost is the emergence of OAFramework applications within the Release 12 footprint which is depicted in the chart to the left.

One of the reasons this is so important is that OAFramework applications look to Oracle User Management (UMX) roles for their security framework which means ever increasing levels of access are being granted through UMX roles rather than through traditional system administration responsibilities and menus. An example of one of these inflection points is in Oracle Cash Management where bank accounts are assigned to Legal Entities through the granting of a specific UMX role. In fact, Oracle Cash Management was redeveloped in OAFramework in Release 12 which is probably a template that Oracle will follow for other applications in future releases.

This emergence of OAFramework challenges our traditional ways to audit the various access levels across the Release 12 footprint. As we all know, Oracle designs “great privilege” into their base deliverables as evidenced by the Payables Manager responsibility and the General Ledger Super User responsibility. “Great privilege” is the second dynamic that is submitted for your consideration. I trust nobody is using the out-of-the-box responsibilities in their production environments, but if “great privilege” is designed into traditional system administration access levels, what about the OAFramework/UMX roles?

Couple “great privilege” with our third dynamic, “inheritance” and you have just poured fuel on the roaring controls fire we’ve been building. “Inheritance” is where a new person inherits all application accesses from another person who has been performing the same role for some period of time. Usually inheritance is a good thing, but in this case, the new AP clerk just inherited all accesses from the other AP clerk who may have been working at that company for 20 years. So, in one simple authorization, the new AP clerk now has 20 years worth of accesses which may or may not be understood, intended nor authorized.

So, let’s recap, there are three dynamics at play here (1) emergence of OAFramework and UMX roles, (2) “great privilege” being designed by Oracle and (3) the ease of “inheritance” which erodes individual authorizations across the Release 12 footprint. Role Based Access Control (RBAC) can mitigate these three dynamics if adopted and designed appropriately. In our next post, we will take a deeper look at RBAC to understand what it is and how it can be designed and deployed at your company to effectively mitigate the new controls inflection points created in Release 12 where traditional system administration meets the emergence of OAFramework and UMX.