Oracle introduced a new module in Release 11.5.10 called UMX to help with User Management. It is a comprehensive module that provides a more secure user administration capability while at the same time providing additional features not found in the ultra-basic user administration forms found in the base 11i System Administrator functions.

With Release 11.5.10, Oracle User Management (UMX) implemented a Role Based Access Control (RBAC) model. Role Based Access Control (RBAC) is an ANSI standard that controls user access control. According to MetaLink Note 290525.1, Oracle User Management FAQ:

The RBAC standard supports mapping user access control based on the role that the user plays within the organization rather than upon the user's individual identity. The benefits of implementing RBAC include:

• Reduced cost of administering user access
• Streamlined setup and implementation of security policies
• Structured user access control based on users' job functions

The RBAC model augments the existing access control model in Oracle Applications by providing additional methods to organize your data security policies and existing function security (via roles). Security privileges in Oracle Applications have up to this point been managed on an individual user basis, with different types of privileges assigned to each user directly. For example, someone in a Support Agent position may have had to be assigned multiple responsibilities and several other types of access privileges in order to perform their job.

By leveraging the RBAC model, users will no longer need to be directly assigned the lower level permissions and responsibilities, as these can be implicitly inherited based upon the roles assigned to the user. Roles can now be defined to consolidate responsibilities and other roles through role inheritance, as well as lower level permissions (functions) and data security policies. This is accomplished through a one-time setup, where all the permissions are assigned to the role. In order to make a mass update in a production system a client only needs to change the permissions or role inheritance hierarchies defined for a role, then all of the users assigned to that role will instantly inherit the new permissions.

Suffice it to say, the UMX module with RBAC is a significant change to consider over the older, existing Oracle Applications security model.

What is the difference between a Role and a Responsibility? MetaLink Note 290525.1 states:

Responsibilities can now be considered a special type of role that represents the set of navigation menus contained within an application. Therefore, responsibilities loosely represent an application itself, whereas roles can be used to determine to what parts of that application (and data therein) a user has access. This represents a shift in the definition of a responsibility in Oracle Applications. Previously, a responsibility has been used not only to define the application navigation menus, but also to confer privileges and permissions within that application. Using this definition of responsibility, it was often necessary to create several similar responsibilities in order to effectively carve out data and functional security access for a group of users. This has increased the overall cost of ownership as the number of responsibilities has grown.

Oracle Applications follows the Role Based Access Control (RBAC) Reference Model (ANSI INCITS 359-2004) definition of a role as "a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role." Roles can now be defined to determine what applications (responsibilities) as well as what data and functions within those applications a user has access to.

In addition to RBAC, UMX also introduces a new concept to the Oracle E-Business Suite called a Registration Process. A Registration process is a method by which an end-user can request varying levels of access to the system based on who they are in their eligibility. What is new or unique, is that the user doesn’t request this via a help desk or by filling out a paper request; rather the system accepts the request, and routes the request through a workflow process, gathering and tracking the needed approvals, notifications and verifications along the way. This simplifies the System Administrator’s job by providing streamlined flows for account administration and maintenance.

Oracle User Management supports three types of Registration Processes:

* Self-Service Account Requests. If you have ever made an on-line transaction, you probably did a self-registration and created an account to tie the order to. This Registration Process type is very similar in that the system provides a method for persons to request a new user account. This type of registration process also offers identity verification, which confirms the identity of the requester (via an email notification that requires a response) before the registration request is processed. If the recipient does not reply within a predetermined amount of time the request will be automatically rejected.
* Requests for Additional Access. Oracle UMX provides an Access Request Tool that enables existing users to request additional roles. Users can only request the additional roles that have been defined as appropriate based on their current roles.
* Creation by Administrators. While the name of this registration process does not sound all that intriguing, the reason it exists presents a much more interesting discussion point. In UMX, the definition of an Account Administrator is changing from that of one or two select individuals working in IT or on the helpdesk to users in the Business Units. With the concept of delegated administration, the ability to create user(s) can be extended beyond the traditional confines of an organization’s IT department into the business, and even beyond the organization to business partners and clients, because each account creation registration process can be made available to select administrators.

> back to list