Access Control with Oracle User Management
Overview
This chapter introduces the Core Security and Administrative Features of Oracle User Management. Core Security includes Oracle's Function and Data Security models, as well as Role Based Access Control. Administrative Features build upon Core Security and include Delegated Administration, Registration Processes, and Self Service and Approvals.
Core Security and Administrative Features are implemented in successive layers and each builds upon the one that precedes it. Organizations can optionally uptake the various layers, depending on the degree of automation and scalability that they wish to build upon the existing Function and Data Security models.
In general, Access Control with Oracle User Management begins with basic system administration tasks, progresses to more distributed, local modes of administration, and ultimately enables users to perform some basic, predefined registration tasks on their own. The following diagram illustrates how the layers build upon each other.
Oracle User Management Layers
Oracle User Management provides support for legacy and application-specific security mechanisms through workflow business events. Oracle User Management raises these events once a user's request is approved. Organizations can then intercept these events, determine the appropriate action, and assign any additional privileges that may be required.
Function Security
Function Security is the base layer of access control in Oracle E-Business Suite. It restricts user access to individual menus and menu options within the system, but does not restrict access to the data contained within those menus. For example, an organization could use Function Security to provide its sales representatives with the required menus and menu options for querying customers. It could also control access to specific components of those pages such as a button on a sales forecasting page. For a more comprehensive explanation of function security, see: Oracle Application Object Library Security.
Data Security
Data Security is the next layer of access control. Building on Function Security, Data Security provides access control within Oracle E-Business Suite on the data a user can access, and the actions a user can perform on that data. Oracle E-Business Suite restricts access to individual data that is displayed on the screen once the user has selected a menu or menu option. For example, Data Security restricts the set of users that a local administrator can access within Oracle User Management. Data Security policies can only be defined for applications that have been written to utilize the Data Security Framework. For a more comprehensive explanation of data security, see Oracle Application Object Library Security.
Role Based Access Control (RBAC)
Role Based Access Control Layer
RBAC is the next layer and builds upon Data Security and Function Security. With RBAC, access control is defined through roles, and user access to Oracle E-Business Suite is determined by the roles granted to the user. Access control in Oracle E-Business Suite closely follows the RBAC ANSI standard (ANSI INCITS 359-2004) originally proposed by the US National Institute of Standards & Technology (NIST), which defines 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."
A role can be configured to consolidate the responsibilities, permissions, function security and data security polices that users require to perform a specific function. This is accomplished with a one-time setup, in which permissions, responsibilities, and other roles are assigned to the role. Users are not required to be assigned the lower-level permissions directly, since permissions are implicitly inherited on the basis of the roles assigned to the user. This simplifies mass updates of user permissions, since an organization need only change the permissions or role inheritance hierarchy defined for a given role, and the users assigned that role will inherit the new set of permissions automatically.
Organizations can define roles that closely mirror their business situation. For example, an organization can create an "Employee" role and then assign that role to all of its employees. It can also create an "External" role and assign that role to customers and suppliers. Further examples may include specific roles such as "Support Agent," "Sales Rep," "Sales Managers." In these examples, each role contains a specific level of access privileges that restricts its assignees to the scope of their job functions. Some members of the organization will probably be assigned more than one role. A sales representative would be assigned the Employee and Sales Representative roles, and a Sales Manager would be assigned the Employee, Sales Representative, and Sales Manager roles. Roles and role assignments are stored in the workflow directory, which is interpreted by the security system at runtime.
Role Categories
As part of the Oracle E-Business Suite RBAC model, Oracle User Management introduces Role Categories. Administrators can create role categories to bundle roles and responsibilities to make the process of searching for roles and responsibilities easier. For example, all sales and marketing related roles could be included in the Sales & Marketing category.
Role Inheritance Hierarchies
Roles can be included in role inheritance hierarchies that can contain multiple subordinate roles and superior roles. With role inheritance hierarchies, a superior role inherits all of the properties of its subordinate role, as well as any of that role's own subordinate roles. The following example demonstrates how role inheritance hierarchies can greatly simplify user access control and administration.
Role Inheritance Hierarchy
In the above figure, the arrows on each side of the diagram indicate membership inheritance and permission inheritance. Text in the rounded boxes indicates roles. An arrow pointing from an individual to a role indicates that this individual is assigned the role. An arrow pointing from one role to another indicates that the role from which the arrow points is the superior role, and the role to which it points is the subordinate role. Permissions associated with a role are inherited by all of its superior roles and the individuals to which any of these roles are assigned.
In this example, some roles such as "Employee" or "Manager" are assigned general permissions for a given function. For example, the Employee role may provide access to menus generally available to all employees, while the Manager role provides access to menus that should only be viewed by managers. Because the Employee role is a subordinate role of the Manager role, anyone assigned the Manager role automatically obtains the permissions associated with the Employee role. Other roles in this example pertain to more specific job functions, such as Sales Manager and Sales Representative, or Support Manager and Support Agent. These roles may provide access to job-specific menus and data such as the Sales Forecasting menu, or the Support application.
Delegated Administration
Delegated Administration Layer
Delegated Administration is a privilege model that builds on the RBAC system to provide organizations with the ability to assign the required access rights for managing roles and user accounts. With delegated administration, instead of relying on a central administrator to manage all its users, an organization can create local administrators and grant them sufficient privileges to manage a specific subset of the organization's users and roles. This provides organizations with a tighter, more granular level of security, and the ability to easily scale their administrative capabilities. For example, organizations could internally designate administrators at division or even department levels, and then delegate administration of external users to people within those (external) organizations. Delegation policies are defined as data security policies. The set of data policies that are defined as part of delegated administration are known as Administration Privileges.
A delegated administrator can be given the capability to perform one or more of the following role management actions: Create Role, Manage Role, Manage Role Hierarchy, Run Security Wizard, Assign Role, and Revoke Role. Older releases required delegated administrators to be given either all role management privileges, or none. Now the administration operations have been separated, so the super administrator can specify which operations can be performed by which delegated administrator on which set of roles.
Administration Privileges
Administration Privileges determine the users, roles and organization information that delegated administrators (local administrators) can manage. Each privilege is granted separately, yet the three work in conjunction to provide the complete set of abilities for the delegated administrator.
-
User Administration Privileges A local administrator must be granted User Administration Privileges to determine the users and people the local administrator can manage. Local administrators can be granted different privileges for different subsets of users. For example, a local administrator can be granted privileges only to query one set of users, and granted full privileges (including update and reset password) for another set. Local administrators cannot query users for which they do not have administration privileges.
-
Role Administration Privileges Role Administration Privileges define the roles that local administrators can directly assign to and revoke from the set of users they manage.
-
Organization Administration Privileges Organization Administration Privileges define the external organizations a local administrator can view in Oracle User Management. This privilege enables an administrator to search for people based on their organization, if the local administrator has additionally been granted access to view the people in that organization (User Administration Privileges). Depending on the user administration privileges, an administrator may have the ability to register new people for that organization.
Oracle E-Business Suite continues to support the traditional "System Administrator" level of administration privileges, where a designated group of people manages all users and access privileges. Oracle User Management ships a predefined Security Administrator role, which gives the administrator the privileges to manage all users including system accounts and all roles in the system.
Delegated administration setup for User Administration requires the creation of instance sets and permission sets. Instance sets can be created from the main UMX screen. All possible combinations of seeded UMX permissions are seeded as permission sets and made available from this screen. A data security object, UMX_SYS_ACCT, represents system accounts. Administrators can create instance sets against this object to specify system accounts that can be managed.
Provisioning Services
Provisioning services are modeled as registration processes that enable end users to perform some of their own registration tasks, such as requesting new accounts or additional access to the system. They also provide administrators with a faster and more efficient method of creating new user accounts, as well as assigning roles. Registration processes accomplish this by encapsulating core components of registration, including:
-
The role(s) assigned after the user successfully completes the process.
-
An optional registration user interface for collecting account or additional information.
-
A workflow for approval, confirmation, rejection, and identity verification notifications.
-
The Approval Management Transaction Type. A transaction type represents a set of approval routing rules that are interpreted at runtime.
-
The set of users that are eligible to sign up for additional access (only applicable for Request for Additional Access registration processes).
-
Whether identity verification is required. Identity verification confirms the identity of a requester before the registration request is processed, by sending an email notification to the requester's email address. If the recipient does not reply within a specified time, the request will be automatically rejected.
-
The set of local administrators that should be able to register people and/or create users through the Account Creation by Administrators registration process.
When a user completes registration using a registration process, the system captures the required information from the user, and subsequently assigns that person a new user account, role, or both. Oracle User Management supports three types of registration processes: Self-service Account Requests, Requests for Additional Access, and Account Creation by Administrators.
Self-Service Account Requests
Commonly referred to as Self-Service Registration, self-service account requests provide a method for individuals to request a new user account. Consider a case where customers may need to register before they can purchase an item from an online store. Once the registration process has been completed, the customer obtains both a user account and the necessary role(s) for accessing some portion of the web site in which they registered.
Oracle User Management provides sample self-service registration UIs for internal employees, and for new, external individuals. Organizations can copy these sample self-service registration UIs and extend them based on their own requirements. In addition, organizations that wish to support other types of users, or capture additional information specific to their applications, are able to extend or create their own registration UIs and business logic.
Oracle User Management provides support for displaying different registration links on the login page based on the application tier login page that provides access. The registration link can contain additional parameters that are not known at design time, such as the country code. These additional parameters can be used later during the registration process. Using country code as an example, a registration process could route the approval requests to the most appropriate approver. Therefore, all those who request an account from Norway could be routed to a Norwegian account approver.
Additional Information: "Accounts" and "User Accounts" refer to login accounts, stored in the FND_USER table.
Requests for Additional Access
Users can request additional access through the Oracle User Management Access Request Tool (ART), available in the Global Preferences menu. Requests for Additional Access uses the same Oracle User Management infrastructure and processing logic as Self Service Account Requests.
Additional Access and Self Service Eligibility
Eligibility defines the Roles for which a user can sign up using the Access Request Tool. It determines the groups of users defined in the workflow directory that are entitled to register for a given role. A registration process of type "Additional Access" can be made available to predefined sets of users across all roles or groups. Eligibility is defined as a data security policy, and interrogated at runtime by the Access Request Tool.
Because roles are stored in the workflow directory, they can be used both to grant access to applications and to define eligibility. This enables organizations to define an incremental registration process in which new users can sign up for roles if they are first approved for the ones that precede them. For example, once a new user is approved for the A Role, the user can then sign up for the B Role. If, however, the user is not first approved for the A Role, then the user cannot sign up for the B Role.
Oracle User Management can define eligibility policies for any groups and roles stored in the workflow directory.
Delegated Administration and Registration Processes
When an administrator assigns a role to a user, the administrator essentially fulfills a registration request on behalf of the user. When the administrator assigns a role to the user, Oracle User Management invokes the corresponding "Additional Access (Administrator)" registration process (if defined) and interprets the registration processes metadata. If a registration UI is defined, Oracle User Management launches it and the administrator completes the registration process. Notification workflows are only invoked when a registration process is defined for the role that is being assigned to the user.
Directly assigning a role to a user bypasses any pre-defined approval routing rules, as defined in Oracle Approval Management. Administrators can view all roles that are assigned to a user, but cannot assign or revoke roles for which they do not have administrative privileges. An administrator assigning a role to a user is essentially fulfilling a registration request on behalf of the user.
Account Creation By Administrators
Administrators benefit from registration processes having been designed to streamline the process of creating and maintaining user access. Registration processes of this type are geared toward administrators, especially delegated administrators, to ensure consistent application of the organization's user security policies. Each account creation registration process can be made available to selected administrators.
Registration Process Infrastructure
This section describes components of the common infrastructure that handles all registration requests submitted through Oracle User Management.
User Name Policies
Oracle User Management enables organizations to define their own user name policies for new users. These can include such formats as email address, "firstname.lastname" (or an abbreviated version), employee number, social security number, or some other meaningful information. When the account request is submitted, Oracle User Management reserves the specified user name for the duration of the approval process.
Oracle User Management ships with a default user name policy that identifies users by their email address. This is implemented as a configurable infrastructure that organizations can easily customize to suit their specific needs.
Email Verification
Oracle User Management provides a mechanism for verifying the identity of the requester before the registration request is processed. Identity verification is based on the email address provided by the requester. Oracle User Management sends the requester an email notification when the requester has completes the registration flow. If the user does not reply to the email notification within a specified time, the request is automatically rejected. Email verification is only applicable to Self-Service account requests, and is enabled or disabled for each registration process.
Note: Oracle recommends that when building self-service registration UIs with identity verification enabled, an organization should indicate in the UIs and confirmation messages that a response is required to process the user's request.
Temporary Storage of Registration Data
Oracle User Management provides a mechanism to store registration data in a pending state until a request is approved. This data is available to the workflow notifications used for sending approvals, to Approval Management routing rules, and to the business logic that writes the information in the final destination tables. Oracle User Management accomplishes this by using event objects that are part of the Workflow Business Events infrastructure.
Registration Engine
The Oracle User Management registration engine uses a workflow to define the business logic that drives the registration process once a request has been submitted. The name of the workflow is UMX Registration Workflow (UMXREGWF).
This process:
-
Raises business events
-
Provides temporary storage of registration data
-
Provides identity verification
-
Includes the integration point with Oracle Approval Management
-
Activates user accounts
-
Reserves and releases user names
-
Assigns roles
-
Maintains registration status in the Oracle User Management schema
-
Launches notification workflows
Organizations can customize the components of the registration process (such as notifications, approval routing rules, and user name policies) without having to review and understand all Oracle User Management code.
Routing Approval Requests
Approvers can be configured based on rules that are specific to each type of request. Organizations can define these rules according to their requirements, and can specify types of requests that do not require approval. Oracle User Management is integrated with Oracle Approval Management, an application that provides a flexible and powerful rules engine that can be configured through declarative means to route approval requests. Oracle User Management also provides APIs that enable approval rules to be based on any information captured during the registration process, including any parameters passed from the "Register Here" link on the Login page, which may not have been known at design time.
Workflow Business Events
Oracle User Management raises the following Workflow business events:
| Event | Description |
|---|---|
| oracle.apps.fnd.umx.rolerequested | An event that is raised when a role is requested. |
| oracle.apps.fnd.umx.accountrequested | An event that is raised when an account is requested. |
| oracle.apps.fnd.umx.requestapproved | An event that is raised when an account or role is approved. |
| oracle.apps.fnd.umx.requestrejected | An event that is raised when an account or role is rejected. |
| <custom event> | A custom business event is raised for the owner of the registration process to write the registration. The custom event is raised multiple times. For more information, see My Oracle Support Knowledge Document 399400.1, Oracle Applications User Management (UMX) Developer's Guide. |
Note: Oracle recommends using the UMX events mentioned above only for centralized requirements such as auditing. For any registration-specific processing, use the custom event defined for the registration process.
Depending on the context, the event parameters listed in the following table are set automatically by the Oracle User Management registration engine when business events are raised. Any additional information captured in the registration UI, approval notifications, or programmatically through business logic is also available as event parameters.
| Name | Description |
|---|---|
| REG_SERVICE_CODE | Represents the primary key of the registration process |
| REG_SERVICE_TYPE | The type of registration process |
| REQUESTED_BY_USER_ID | Identifies the user submitting the request |
| REQUESTED_FOR_USER_ID | Identifies the user for whom the request is submitted |
| REQUESTED_USERNAME | The requested user name |
| WF_ROLE_NAME* | Represents the primary key value of the requested role or the default role for any account requests |
| AME_TRANSACTION_TYPE_ID | Represents part of the primary key for the transaction type in Oracle Approval Management |
| AME_APPLICATION_ID | Represents part of the primary key for the transaction type in Oracle Approval Management |
* WF_ROLE_NAME is not required for Self Service Account Creation or Account Creation for Administrators registration processes. In such cases, a null value is passed. Any additional information captured in the registration UI, from approvers, in approval notifications, or set by business logic is also available as parameters when an Oracle User Management business event is raised.
Sample Program
/**************************************************************
This is a sample subscription to any of the above events.
Function custom_logic (p_subscription_guid in raw,
p_event in out NOCOPY WF_EVENT_T)
Return varchar2 is
l_first_name varchar2(30);
Begin
l_first_name := p_event.getvalueforparameter ('FIRST_NAME');
// Manipulate the data
End custom_logic;
**************************************************************/
Registration Status
Users can check registration status of requests through the Access Request Tool (ART) and administrators can do so using the Administration screens. For any pending requests, the Show Info icon shows the current approver and confirmation number. The confirmation number represents the number (ITEM_KEY) of the Oracle User Management Registration Workflow (UMXREGWF) workflow process handling the request.
Notification Workflows
Notification workflows enable an organization to define its own email notifications that are specific to each Role or Registration Process. Notifications include:
| Notification | Recipient |
|---|---|
| Approver notifications | Each approver. |
| Approval confirmation notifications | Individual for whom the request was filed. |
| Rejection notifications | Individual for whom the request was filed. |
| Identity verification notifications | Individual for whom the request was filed. |
For each request that requires approval as determined by the Oracle Approval Management Engine, Oracle User Management invokes the notification workflow to request approval. Notification workflows can be written to allow approvers to review the information submitted in the registration process, make changes, and provide additional information if required.
Any changes or additional information provided can be passed back to the Oracle User Management registration engine for further processing. For example, if Oracle User Management is used to provide self service registration capability for iSP (Internet Supplier Portal), then approvers can provide additional information about site and contact restrictions for the requester. Information entered by previous approvers, including comments, are available to subsequent approvers.
Oracle User Management provides the following sample notification workflows that organizations can use directly or can copy and modify based on their requirements:
| Name | Item Type | Description |
|---|---|---|
| Oracle User Management Additional Access Request notification workflow | UMXNTWF1 | Sends notifications pertaining to all requests for additional access. |
| Oracle User Management Notification Workflow (Account Request) | UMXNTWF2 | Sends notifications pertaining to all account requests. |
Self-Service and Approvals
Self-Service & Approvals Layer
Once registration processes have been configured as required, individuals can subsequently perform self-service registration tasks, such as obtaining new user accounts or requesting additional access to the system. In addition, organizations can usethe Oracle Approvals Management engine to create customized approval routing for these requests. For example, an organization may enable users to request a particularly sensitive role: however, before the user is granted the role, the organization can require that two senior members of staff, such as a manager and a vice president, must approve the request.
Oracle User Management also provides self-service features for resetting forgotten passwords, and ships with the following sample self-service registration processes:
-
Employee Self-Service Registration
-
Customer Self-Service Registration (external individuals)
Organizations can either use these registration processes in their existing form, or as references for developing their own registration processes.
Access Control With Proxy Users
There are a number of business scenarios in which Oracle E-Business Suite users need to grant delegates the ability to act on their behalf (act as proxy users for them) when performing specific Oracle E-Business Suite functions. Traditionally, delegators have done this by giving passwords for specific applications to other users, though that method of delegating access has always been considered insecure. A delegate (the proxy user) who was given another user's passwords for certain applications could assume the identity and privileges of the delegator within those applications, and only those applications.
The integration of Oracle E-Business Suite with single sign-on (SSO) solutions accentuates the drawbacks of this all-or-nothing strategy. If a delegator grants a delegate access to his SSO password, the delegate will be able to access every SSO-enabled application to which the delegator has access, not just specific applications. The proxy user feature is designed to enable limited, auditable delegation of privileges from delegators to their delegates.
Examples of Delegation
There are a number of common scenarios where a user may need to allow another user or users to interact with Oracle E-Business Suite on the original user's behalf:
-
Executives allow their assistants ongoing access to selected business applications on their behalf
-
Users grant peers or subordinates limited authority for a limited duration to act on their behalf while they are out of the office
-
Users grant help-desk staff or other agents limited-duration access to their Oracle E-Business Suite accounts to get help and training
-
Users delegate to internal audit personnel responsible for monitoring regulatory compliance
-
Several users may share a common account
-
Users may need to grant access to others to increase throughput during peak business periods
The Proxy User Feature
The proxy user feature in Oracle E-Business Suite allows users to delegate access to specific application functionality to one or more proxy users. The delegator can grant access to specific responsibilities or workflow notification types to the proxy user, rather than having to grant access to all functionality. This provides the flexibility needed to meet typical business scenarios.
A user with the Security Administrator role must configure the proxy user feature initially within the User Management responsibility.
The administrator specifies:
-
Which users can create delegates who can act on their behalf. The administrator can give all users the privileges to delegate access to other users, or select particular roles or responsibilities whose users can delegate access. Alternatively, the administrator can assign the Manage Proxies role to individual users to allow those users to grant access to proxy users.
-
Which responsibilities can never be delegated. For example, responsibilities that allow a user to change personal information or see their own salary may be deemed too sensitive to allow access by other users.
-
Which users a delegator can select as proxy users. For example, users may only be allowed to grant access to their functionality to their own managers and direct reports, rather than any user on the system.
See: Managing Proxy Users for information on how to configure and manage the proxy user feature in your installation.
Once a user has delegation privileges, setting up proxy users is straightforward. The delegator accesses the Manage Proxies menu from the Settings link or gear icon at the top of the home page or any Oracle Application Framework-based page. See: Delegating Proxy User Privileges.
The delegator can later track which pages were accessed by the proxy user. For more in-depth auditing, the administrator must set up Audit Trail for the specific tables of interest. An administrator with the FND_PROXY_AUDIT permission can review Audit Trail data for actions performed by a proxy user for any delegator.