Wednesday, February 20, 2008

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.


Karthik said...

I would like to know abt RBAC
process-please provide me information

neelu said...

I greatly appreciate every one of the informative read here. I most certainly will spread the phrase about your site with people. Cheers.
Basel hotels

vishus said...

I needed to write down a brief notice in buy to thanks for all the fantastic suggestions you're placing at this website. My prolonged internet lookup has at the finish of the day been recognized with reliable details and techniques to trade with my co-workers. I would assert that several of us readers really are seriously lucky to live in a important location with quite several excellent individuals with insightful pointers.
Hotels In Antwerp

mahakk01 said...

This is an informative post. You get to know RBAC, UMX and release 12. These all terms are new for me but I really understand them well after reading your blog. So I suggest those who have interest can read this post. Thanks.
sap support packs

aliya seen said...

This is a best to understand the qualitative and quantitative data analysis for their large data. I also love this post.