Skip Headers

Oracle E-Business Suite System Administrator's Guide - Security
Release 12.1
Part Number E12843-05
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Oracle User Management Setup and Administration

Setup Tasks

This section discusses the setup tasks for Oracle User Management. The implementor or system administrator sets up access control and security policies in Oracle E-Business Suite by defining roles, role inheritance hierarchies, role categories, and registration processes. These components specify the different levels of access to various application menus and data that are available to administrators.

Defining 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. In the Oracle User Management Overview section, see Role Based Access Control (RBAC).

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Role Categories subtab.

  2. Go to the editable table, click the Update button and then click the Create Lookup Code button.

  3. Enter the required information in the Create Lookup Code fields and click the Apply button.

Creating and Updating Roles

In Oracle E-Business Suite, a role represents a job function that confers the privileges required to perform that job. Roles can be defined to determine what applications (responsibilities) as well as what data and functions within those applications users can access. In the Oracle User Management Overview section, see Role Based Access Control (RBAC).

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. Click the Create Role button.

  3. Enter the required information to configure your role and optionally continue to configure it by accessing the following:

  4. Click Save or Apply to save your changes.

  5. Optionally update the role by performing the following:

    1. Locate the role you want to modify by using the Search fields or by expanding the appropriate nodes in the Role Inheritance Hierarchy menu.

    2. Click the Update icon and modify the role as required.

Guidelines

The Save button saves your changes and continues to display them in the current page. The Apply button saves your changes and returns to the previous page. You can optionally organize your roles using role categories during the process of creating and updating roles, otherwise they will be stored under the "Miscellaneous" role category by default. For more information, see role categories. You can also define any required subordinate roles or superior roles through role inheritance hierarchies.

Security Wizard

The Security Wizard page lists the security wizards available to the currently logged-in user. After launching the wizard by clicking its name, the user can use it to set up the data security policies associated with the role. After completion of the wizard, the user will be returned to the Create/Update Role UI.

Assigning Permissions to Roles

You can assign permissions to a role by creating a grant that specifies the navigation menu, permission sets, and/or the data security policies that are available at runtime to the role's assignees. Menus and permission sets in turn include individual functions and permissions. In the Oracle User Management Overview section, see Role Based Access Control (RBAC).

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. In the Role Inheritance Hierarchy, access the role to which you want to assign a permission and click the Update icon.

  3. Click the Permissions subtab and the click Create Grant button.

  4. Define the grant by entering the required information and clicking Next:

    1. Enter the required information to identify the grant, such as Name and Effective From date.

    2. Security Context. These optional parameters restrict the availability of the permissions being assigned. If you do not define the security context, then permissions are available to users in all contexts. Security contexts are also referred to as Activation Contexts.

      1. Operating Unit. In many cases, an organization consists of several different operating units. You can limit your grant to only be active in the context of an individual operating unit.

      2. Responsibility. Responsibilities determine the applications that can be accessed by users. You can optionally limit your grant to be available only in the context of an individual responsibility, or with all responsibilities.

    3. Data Security. You must select a business object when you create Data Security policies. For more information, see the Oracle Application Object Library Security chapter.

  5. If you have defined a specific object in the preceding step, then choose the object data context for the object, also referred to as the data scope. Specifying the object data context provides an additional level of access granularity for the object. Choose one of the following from the Data Context menu:

  6. Select the required permission set or navigation menu containing the functions (permissions) that you wish to assign to the role, by choosing an option from the LOV.

  7. Review your grant information and click Finish.

Searching For Assigned Roles

The number of roles and responsibilities in some installations can be in the tens of thousands, or even more. Since any given user can potentially have a very large number of roles and responsibilities assigned, it can be very time-consuming to determine which roles have been assigned to which users.

A search capability allows administrators to look for:

Steps

  1. Navigate to the User Management responsibility and then click the Users sub-tab.

  2. Use the search fields to locate the required people or users.

  3. Click on the "Update" icon.

  4. Select any of the above specified criteria, such as "Specific Role" in the drop-down menu and "Sales Manager" in the text box.

  5. Click on the "Go" button.

the picture is described in the document text

Examples

Diagnostics for User-Role Assignment

UMX is heavily dependent on Concurrent Manager, Deferred Agents and Background engines. If any of these are down, the assignments do not take place or may only take place after an excessively long time.

A diagnostic feature built in the User-Role Assignment page checks that the required processes are running when an update is submitted. If they are all running, it reports how much time may be needed for the changes to be effected.

the picture is described in the document text

If one or more are down, the diagnostic feature displays a warning and advises which processes will need to be started in order for the changes to be made successfully.

the picture is described in the document text

Creating Instance Sets and Permission Sets

Delegated administration setup for User Administration requires the creation of instance sets and permission sets. All possible combinations of permissions are seeded as permission sets that are 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.

Steps

  1. Log on as a user who has been assigned the Security/LSA Administrator role (typically as sysadmin), select the User Management responsibility in the navigator.then click the Roles & Role Inheritance subtab.

  2. In the role hierarchy, access the role to which you want to assign user administration privileges, and click the Update icon.

  3. Click on the Security Wizards button.

  4. Click on the Run Wizard icon for "User Management: Security Administration Setup".

  5. Click the User Administration sub-tab, then click the Add More Rows button.

  6. In the Users field, select the set of users that can be managed by Administrators to whom the role is assigned. The drop down list contains various data security policies that relate to the User Management Person Object (UMX_PERSON_OBJECT) and User Management: system accounts object (UMX_SYS_ACCT). The user can now create his own policies on both these objects by clicking on the link "Create Instance Set For Users".

  7. In the Permissions field, select the permissions to be associated with the delegated administration role. The Permissions drop down list includes permission sets that contain permissions associated with the User Management Person object and User Management: system accounts object. All possible combinations of the existing permissions have been seeded here, enabling organizations to add permission sets based on their general business needs and the level of granularity they prefer for administering users.

Create Instance Set (Data Security Policy)

the picture is described in the document text

Selecting Required Permission Set (Data Security Policy)

the picture is described in the document text

This capability means that there is no longer any need to navigate to the Functional Administrator or Functional Developer responsibilities when creating permission sets and instance sets, so that the entire delegated administration set up should now take no more than a few minutes.

Defining Delegated Administration Privileges for Roles

Delegated 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. In the Oracle User Management Overview section, see Delegated Administration.

Defining User Administration Privileges for Roles

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.

Oracle User Management ships with the following seeded permissions for defining user administration privileges for roles:

Seeded User Administration Permissions
Function Code Display name Description
UMX_OBJ_ACTIVATE_ACCT Create, Inactivate, Reactivate User Account, Update Username Permission for creating, inactivating, and reactivating user accounts, and updating username. Must be granted with a data security policy on the User Management Person.
UMX_OBJ_EDIT_PERSON Edit Person Details Permission for editing person details. Must be granted with a data security policy on the User Management Person (UMX_PERSON_OBJECT) business object.
UMX_OBJ_PASSWD_MGMT Reset Password Permission to reset passwords. Must be granted with a data security policy on the User Management Person (UMX_PERSON_OBJECT) business object.
UMX_OBJ_VIEW_PERSON Query Person Details Permission to query person details Must be granted with a data security policy on the User Management Person (UMX_PERSON_OBJECT) business object.

Note: This is the minimum permission required by any security administrator that wishes to manage people and users in Oracle User Management.

UMX_SYSTEM_ACCT_ADMINSTRATION Maintain System Accounts (users not linked to a person) Create, Inactivate, Reactivate, Reset Password for all System Accounts (defined as user accounts not associated with a person).

Note: Only grant to System Administrators.

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. In the role hierarchy, access the role to which you want to assign user administration privileges and click the Update icon.

  3. Click on the Security Wizards button.

  4. Click on the Run Wizard icon for "User Management: Security Administration Setup".

  5. Click the User Administration subtab and then click the Add More Rows button.

  6. In the Users field, select the set of users that can be managed by Administrators to whom the role is assigned. The drop down list contains various data security policies that pertain to the User Management Person Object (UMX_PERSON_OBJECT). Oracle User Management ships with sample data security policies for users. Organizations can use these policies or create their own. For more information, see Defining Data Security Policies.

  7. In the Permissions field, select the permissions that you wish to associate with the delegated administration role. Permissions determine the actions an administrator can perform when managing the set of users defined in the previous step. The Permissions drop down list includes permission sets that contain permissions associated with the User Management Person object. Different combinations of the existing permissions can be grouped into new permission sets, enabling organizations to add permission sets based on their business needs and the level of granularity they prefer for administering users. For more information, see Permission Sets.

  8. Click Save or Apply to save your changes.

Guidelines

Delegated administration can provide different permissions on different subsets of users. Once you define users and permissions for a role, you can optionally view the permissions that belong to the permission set by clicking the Show node. You can also remove the user administration privileges for a set of users by clicking the Remove icon.

Defining Role Administration Privileges for Roles

Role Administration Privileges define the roles that local administrators can directly assign to and revoke from the set of users they manage.

Oracle User Management ships with the following seeded permission for defining role administration privileges for roles:

Seeded Role Administration Permission
Function Code Display Name Description
UMX_OBJ_ADMIN_ROLE Assign/Revoke Role Permission for assigning/revoking roles in the User Management application. Must be granted with a data security policy on the User Management Role (UMX_ACCESS_ROLE) business object.

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. In the navigation menu access the role for which you want to define role administration and click the Update icon.

  3. Click on the Security Wizards button.

  4. Click on the "Run Wizard" icon for "User Management: Security Administration Setup".

  5. Click the Role Administration link and use the Available Roles fields to search for the role(s) that you want to associate with this role and which administrators can manage once they are assigned this role.

  6. Select the desired role(s), move them to the Selected Roles column and click Save or Apply.

Guidelines

The Save button saves your changes and continues to display them in the current page. The Apply button saves your changes and returns to the previous page.

Defining Organization Administration Privileges for Roles

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, assuming the local administrator has also been granted access to view the people in that organization (User Administration Privileges). Depending on what administration account registration process has been granted, the administrator may have the ability to register new people for that organization.

Oracle User Management ships with the following seeded permission for defining organization administration privileges for roles:

Seeded Organization Administration Permission
Function Code Display Name Description
UMX_OBJ_VIEW_RLTNSHPS Query/Register Organization Relationship Permission to query/register organization relationship. Must be granted with a data security policy on the User Management Organization (UMX_ORGANIZATION_OBJECT) business object.

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. In the navigation menu access the role to which you want to define organization administration and click the Update icon.

  3. Click on the Security Wizards button.

  4. Click on the "Run Wizard" icon for "User Management : Security Administration Setup".

  5. Click the Organization Administration link and then click the Assign Organization Privileges button. The drop down list contains various data security policies that pertain to the User Management Person Object (UMX_PERSON_OBJECT). Oracle User Management ships with sample data security policies for organization administration privileges. Organizations can use these policies to create their own.

  6. Search for and select the appropriate organization privileges.

  7. Click Save or Apply to save your changes.

Guidelines

The Save button saves your changes and continues to display them in the current page. The Apply button saves your changes and returns to the previous page.

Defining Data Security Policies

With Oracle E-Business Suite, organizations can use Data Security to manage permission assignments that control access to objects. Data Security policies can only be defined for applications that have been written to utilize the Data Security Framework. For more information, see Data Security. Access to the specific object must be formed with a specified Data Security Policy (also referred to as the Data Scope or Access Policy). The Data Security Policy restricts operations so that they only can be performed on a subset of instances of the corresponding database object. For more information, see Object Instance Sets.

Steps

  1. Log on as a user with the Functional Developer responsibility, click the Functional Developer responsibility in the navigator, navigate to the Security tab and then click the Objects subtab.

  2. Search for and access the object for which you want to create data security policies. For example, to locate the User Management Person business object (UMX_PERSON_OBJECT), enter "UMX%" in the Code field, click the Go button, and then click User Management Person object (UMX_PERSON_OBJECT) in the search results list. For any object for which you are creating a policy, ensure that the SQL statement returns the primary key value for that object. In this example, this is a list of person party IDs.

  3. Click the Object Instance Sets subtab. Click the Create Instance Set button to create a new object instance set or click the Update icon to modify an existing one.

  4. Enter the required information and then click the Apply button.

Caution: For performance reasons, ensure that SQL predicates are tuned properly. For security reasons, ensure that they are tested and that they return the correct result. Oracle is not responsible for the performance or correctness of data security policies defined by organizations.

Defining Role Inheritance Hierarchies

With role inheritance hierarchies, a role can contain sub roles. When a user is assigned a role, the user inherits the privileges defined for that role and for all of its sub roles. For example, the Sales Manager role can contain the Manager and Sales Rep roles, both of which in turn contain the Employee role. Any individual who is granted the Sales Manager role automatically inherits the Manager, Sales Rep and Employee roles.

Role Inheritance Hierarchies

the picture is described in the document text

With Role Inheritance Hierarchies, roles inherit the permissions assigned to their sub roles.

Steps

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Roles & Role Inheritance subtab.

  2. Locate the role for which you want to create a role inheritance hierarchy by using the Search fields or by expanding the appropriate nodes in the Role Inheritance Hierarchy menu. If you are building a role inheritance hierarchy that contains several roles, start with highest level role to which you want to add inherited subordinate roles.

  3. Click the Add Node icon next to this role.

  4. In the resulting menu, search for the role either by using the Search fields or by locating it in the Role Inheritance Hierarchy menu.

  5. Select the role and then click the Select button or the Quick Select icon.

  6. Repeat this process until you have added all of the required subordinate roles to their corresponding super roles. You can optionally verify the results by expanding the nodes for all super roles within your role inheritance hierarchy. You can also remove any subordinate roles by clicking the Remove Node icon.

Deployment Options

Organizations can use different deployment options for role inheritance hierarchies depending on their requirements.

Assigning Existing Responsibilities to Roles Using Role Inheritance

Organizations that have already defined their responsibilities can utilize RBAC by creating roles and assigning their existing responsibilities to those roles. For example, an organization could create an Employee role and a Manager role, and add to these the Expenses and Human Resources responsibilities that it wishes to make available to employees and managers respectively. Then, instead of manually assigning or revoking each of these responsibilities to or from its employees, the organization can simply assign or revoke the Employee and Manager roles as required. Since the Manager role inherits the employee role, managers that are assigned the Manager role also inherit all the responsibilities and privileges associated with the Employee role.

In the following example, a Human Resource Manager inherits the Human Resources Manager Self Service responsibility through the Manager role as well as the Human Resources Employee Self Service responsibility, which the Manager role inherits from the Employee role.

Note: In this section, references to the Expenses and Human Resources responsibilities are used as examples only. Some applications may require organizations to create multiple responsibilities to operate with their existing security models. For more information, please consult the application-specific documentation.

Assigning Existing Responsibilities to Roles Using Role Inheritance

the picture is described in the document text

Steps

  1. Create roles representing the required job functions such as Manager and Employee.

  2. Define a role inheritance hierarchy. For more information, see Defining Role Inheritance Hierarchies.

  3. Ensure the responsibilities are inherited by their corresponding roles.

  4. Assign the roles to users as required.

Fully Utilizing RBAC and Role Inheritance to Determine Access to an Application

In older releases of Oracle E-Business Suite, access to individual functions within an application could only be defined through responsibilities, menu hierarchies, and menu exclusions. Responsibilities had the dual role of defining application navigation menus and granting permissions to the application. New responsibilities with one of the following had to be defined for each set of users with different job functions that required access to a set of pages within an application:

The Human Resources application, for example, typically required a minimum of two responsibilities, one for employees and one for managers.

Separating Navigation Menus and Access Control

Oracle User Management provides new alternatives for defining access to an application with RBAC and Role Inheritance, allowing organizations to separate navigation menus from access control. Responsibilities can now be defined to represent an application itself and as a result, only one responsibility may be required for each application. A menu can be tailored for each application with specific consideration to usability and end user navigation experience. Access to parts of the application (responsibility) and its corresponding menu hierarchy are instead controlled by different roles, each representing a specific job function or set of people.

Benefits

Using this mechanism for determining access control provides several benefits.

Steps

Note: In this section, references to the Expenses and Human Resources responsibilities are used as examples only. Some applications may require organizations to create multiple responsibilities to operate with their existing security models. For more information, please consult the application-specific documentation.

  1. Define a new responsibility that will be used to represent a specific application such as Expenses or Human Resources. For more information, see Defining a Responsibility.

  2. Design a complete menu that includes all the menu functions within an application as well as any required submenus, and attach this menu to the new responsibility. For example, both the Expenses and Human Resources responsibilities would include all employee and manager menus. For more information, see Defining a New Menu Structure.

  3. Following the "principle of least privilege", all the menu options within the application (each menu item corresponds to a function/permission) should be disabled by default. To accomplish this, remove the selection from the "grant" checkbox for each menu item:

    The following figure illustrates application responsibilities (in this case, Expenses and Human Resources) with all their menus disabled:

    Responsibilities Representing an Entire Application with Disabled Menus

    the picture is described in the document text

    Note: A user cannot access any of the menu items (functions) within the application if you assign the responsibility to the user at this stage.

  4. Create roles representing the people with various job functions that require access to the application, for example, a Manager role and an Employee role. For more information, see Creating and Updating Roles

  5. Define role inheritance relationships. For more information, see Defining Role Inheritance Hierarchies For example, the Manager role should inherit the Employee role, and the Employee role should inherit the Expenses and Human Resources responsibilities. The following figure illustrates a role inheritance relationship in which a role inherits the responsibilities that are inherited by its subordinate role:

    Role Inheritance Relationship in Which a Role Inherits the Responsibilities Inherited by its Subordinate Role

    the picture is described in the document text

  6. Assign permissions to each role. For more information, see Assign permissions to each role. Each permission maps to a menu item (function) within the application (responsibility) that should be available to the users to whom the role is assigned. For example, an organization will grant the employee-related permissions from the Expenses and Human Resources responsibilities to the Employee role, and will grant the manager-related permissions for these responsibilities to the Manager role. Consequently, the manager role will have access to all the menu items within these responsibilities, but the Employee role will only have access to the Employee-related functions.

    Permissions, Roles and Inheritance

    the picture is described in the document text

    Permissions assigned to a subordinate role in the role inheritance hierarchy are automatically inherited by the superior roles. For example, if you grant the permission for accessing the Online Tax Forms page to the Employee role, anyone with the Manager role will automatically have access to this page through role inheritance. Because the Hire and Fire Directs page is only granted to the Manager role, it is not available to users that are only assigned the Employee role.

    Permissions are always assigned through permission sets, which represent named sets of functions (permissions). When determining what permissions (functions/menu items) should be granted to each role, you may have to create new permission sets. Menus and permission sets are stored in the same tables in the database; which means that they are interchangeable (both can be used) to assign permissions.

  7. Optionally assign any additional permissions and data security policies to roles as required by each application.

Guidelines

Oracle User Management ships with the following Customer Administrator and Security Administrator roles. These roles illustrate how to setup Roles and Role Inheritance to determine user access within an application (responsibility). Both roles inherit the User Management responsibility but each role is granted different permissions and data security policies. The User Management responsibility has the grant flag removed for all functions (permissions) in the menu hierarchy. Instead, these permissions are granted to the role depending on each role's requirements:

Role Attributes and Roles
Role Attributes Customer Administrator Security Administrator
Permission Sets
  • User Maintenance UIs

  • User Maintenance UIs

  • Setup screens

  • Maintain system accounts

User Administration
  • Data security policies to manage people and user accounts for the customer administrator's own organization

  • Typically, the Customer Administrator can only assign or revoke a subset of roles

  • Data security policies to manage all people and user accounts

  • The Security Administrator can assign or revoke all roles

Other Permission
  • N/A

  • ICM Override Privilege

Creating and Updating Registration Processes

Registration processes are predefined registration components that enable end users to perform some of their own registration tasks, such as requesting new accounts or requesting additional access to the system. They also provide administrators with a faster and more efficient method of creating new user accounts.

Oracle User Management provides four types of registration process:

In the Oracle User Management Overview section, see Registration Processes.

Steps

Registration processes all use the same infrastructure and processing logic. Steps for defining a registration process will vary depending on the type of registration process you are creating.

  1. Log on as a user that is assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator and then click the Registration Processes subtab.

  2. Click the Create Registration Process button.

  3. Enter the required information for the Registration Process Description and click the Next button. This information specifies:

  4. Enter the runtime execution information for the registration process and click the Next button. This information specifies:

  5. Enter the eligibility information for the registration process by selecting the appropriate roles or groups from the Available Groups column and clicking the Submit button. For Self-Service Requests for Additional Access, eligibility defines the users who are able to register for the role associated with the registration process. For Account Creation by Administrators, eligibility determines what administrators can register new users through the registration process. Oracle User Management ships with the following seeded permissions for defining eligibility policies:

    Seeded Permissions for Self Service Additional Access and Account Creation by Administrators Eligibility
    Function Code Display Name Description
    UMX_OBJ_ADMIN_CRTN_FLOW Administrator Assisted Account Creation Permission representing "Administrator Assisted Account Creation" registration processes. This must be granted as a data security policy on the Registration Process (UMX_REG_SRVC) business object.
    UMX_OBJ_ROLE_ELGBLTY Self Service Eligibility Permission representing registration processes for additional access. Determines the set of end users that should be eligible to register for a given role/registration process. This must be granted as a data security policy on the Registration Process (UMX_REG_SRVC) business object.
  6. Register subscriptions to the appropriate business events raised by Oracle User Management, and ensure that your subscription logic writes the registration data into the appropriate destination schemas.

  7. Optionally update the registration process by searching for it and clicking the Update button in the search results page.

  8. Optionally set the following profile options for registration processes of type Self Service Account Request:

Note: The Apache server may need to be restarted for the changes to take effect.

Configuring the User Name Policy

The Oracle User Management registration infrastructure supports a configurable user name policy. This policy is used to generate a suggested user name in the sample user creation flows shipped with the application, as well as for validating the chosen user name format.

Note: Oracle User Management is supplied with a default policy that identifies users by their email address.

Seeded User Name Policies

The following table lists the seeded user name policies that are shipped with Oracle E-Business Suite.

Seeded User Name Policies
Code Description
UMX_USERNAME_POLICY:EMAIL_ADDRESS User name policy with email address format defined as the policy.
UMX_USERNAME_POLICY:NONE User name policy with no restriction on user name format.

Administrators can configure either of these seeded policies. In addition to these, custom policies can also be implemented if desired.

Note: For details of how to create a custom policy, see the UMX Developer's Guide, Knowledge Document 399400.1 on My Oracle Support.

Configuration of user name policy is a three-stage process.

Stage 1 - Suggested User Name Generation Subscription Setup

  1. Log on as a user that is assigned the Workflow Administrator Web Applications responsibility (typically sysadmin).

  2. Go to Workflow Administrator Web Applications > Business Events

  3. From the Business Events page, search for the Business Event with the name oracle.apps.fnd.umx.username.generate.

  4. Click on the Subscription icon to go to the Subscriptions page.

  5. For the subscription corresponding to the policy, change the status to “Enabled”.

Stage 2 - Validation Event Subscription Setup

  1. Log on as a user that is assigned the Workflow Administrator Web Applications responsibility (typically sysadmin).

  2. Go to Workflow Administrator Web Applications > Business Events

  3. From the Business Events page, search for the Business Event with the name oracle.apps.fnd.user.name.validate.

  4. Click on the Subscription icon to go to the Subscriptions page.

  5. For the subscription corresponding to the policy, change the status to “Enabled”.

Stage 3 - Profile Option Setup

  1. Log on as a user that is assigned the Functional Administrator responsibility (typically sysadmin).

  2. Go to Functional Administrator > Core Services > Profiles

  3. Search with the Profile Name of UMX: User Name Policy in the Maintain Profile Options page.

  4. Click on the Update icon to go to the Update Profile Option page.

  5. Choose a value corresponding to the policy and click on the Apply button.

Additional Requirements

Delegated Administration Tasks

The Delegated Administration layer of Access Control in Oracle E-Business Suite enables local administrators to perform a variety of specifically defined administrative tasks. Once they are assigned the appropriate roles, local administrators manage the subset of users and people to which they have access by creating, updating, or disabling accounts, granting or revoking a limited subset of their organization's roles, and changing passwords.

Maintaining People and Users

Oracle User Management enables local administrators to manage people and users in the system. People are individuals in the system who may or may not possess a user account, whereas users are individuals in the system who possess user accounts. In addition, system administrators can also manage system accounts that are not linked to people.

Typically, people and users are managed by local administrators, who can perform the following tasks:

Common Prerequisites

The following are prerequisites for performing any delegated administration task listed in the preceding section. Each task may have additional prerequisites:

Steps

  1. Navigate to the User Management responsibility and then click the Users subtab.

  2. Use the search fields to locate the required people or users.

  3. Manage the generated list of people or users by clicking the required icon and performing the necessary steps in the resulting window. Options for managing people and users vary depending on the permissions assigned to the administrator. Oracle User Management ships with the following basic and advanced options for maintaining people and users:

Creating, Inactivating, and Reactivating User Accounts

Administrators can create a user account for any person in the system who does not already possess one.

Prerequisites

To create, inactivate, and reactivate user accounts, an administrator must be assigned the following:

By default, user names are derived from the person's email address.

Steps

  1. Log in as a user with a role granting you access to the User Management responsibility, select the User Management responsibility in the navigator and click the Users subtab.

  2. Search for the person for whom you wish to create an account and then click the Create Account icon next to the person's name if the account does not already exist. Your search will only generate results for the subset of users that you are eligible to manage.

  3. Enter or modify the required information and click the Submit button.

Guidelines

Oracle recommends that you base user names on the person's email address.

Resetting User Passwords

Oracle User Management enables administrators to reset passwords for the set of users in the system that they manage. When the password is reset, an email message is sent to the user using the UMX Password (UMXUPWD) workflow.

Prerequisites

To reset user passwords, an administrator must be assigned the following:

Steps

  1. Log in as a user with a role granting you access to the User Management responsibility, select the User Management responsibility in the navigator and click the Users subtab.

  2. Use the Search field to locate the user whose password you wish to change and then click the Reset Password icon next to the user.

  3. Select one of the following options, provide any required information and click the Submit button.

The person for whom you reset the password receives and email notification stating that the password has expired and must be reset the next time the user logs in. This notification is sent by the UMX Password (UMXUPWD) workflow.

Unlocking Locked User Accounts

Oracle User Management enables administrators to unlock user accounts that have been locked due to unsuccessful attempts to log in using an incorrect password.

Prerequisites

To unlock an account, an administrator must be assigned the following:

Steps

  1. Log in as a user with a role granting access to the User Management responsibility.

  2. Select the User Management responsibility in the navigator, and click the Users subtab.

  3. Use the Search field to locate the user whose account you wish to unlock. The user account is locked if the Account Status column displays a padlock icon along with status "Locked".

  4. Click the "Reset Password" icon next to that user and follow the steps mentioned in the section above to reset the user's password. As a result of resetting the password, the user account will be unlocked.

Assigning Roles to or Revoking Roles from Users

Oracle User Management enables administrators to assign roles to or revoke roles from the subset of users that they manage.

Prerequisites

To assign roles to or revoke roles from users, an administrator must be assigned the following:

Steps

  1. Log in as a user with a role granting you access to the User Management responsibility, select the User Management responsibility in the navigator, and click on the Users subtab.

  2. Search for the person to whom you wish to assign roles or from whom you wish to revoke roles.

  3. From the search results table, navigate to the User Details page by clicking on the Update icon next to the person's name.

  4. To assign a role to the user, click the Assign Roles button on the User Details page and select the desired role.

    To revoke a role from the user, you must end-date the role. If the role is an inherited role, you can only remove it by removing the role from which it originates in the role inheritance hierarchy. You can view a role's inheritance hierarchy by clicking on the Show hyperlink next to the role.

Additional Guidelines

The administrator can only grant or revoke roles for which he has the appropriate privileges. If a registration process exists for the role, it will be invoked and the request will be handled by the Oracle User Management registration engine. If not, then the role is assigned directly. If the role is associated with a registration process for existing users and the registration process has a reference for capturing additional information, then the "Additional Information Required" link is rendered. The administrator must click on this link and provide any required additional information before the request is processed.

Fine Grained Access Control for Role Administration

Fine grained access (FGA) control for roles extends the delegated administration functionality by securing administrator operations for role administration. Fine Grained Access for RBAC (FGA for RBAC) , provides the functionality to support requirements.of the form “this administrator can run security wizards for some roles but not others”. More specifically, FGA for RBAC allows a security administrator to set up a limited administrator, who can only perform restricted actions on a role.

The following privileges are available for administering roles:

The security administrator can define privileges for roles via the Role Administration tab on the Delegated Administration Screen.

Steps

  1. The Security Administrator creates a new role, such as one called Limited Security Administrator, then enables FGA on this role by running the Delegated Administration setup wizard.

  2. In the setup’s Role Administration tab, the Security Administrator creates a new role administration criterion, for example HRMS Role Administration. A criterion is simply a set of roles to which a set of privileges can be assigned. An administrator role can be associated with any number of criteria.

  3. The Security Administrator assigns the Assign Role and Manage Grants privilege to this new criterion.

Any administrator to which the new Limited Security Administrator role is assigned will only be able to administer those roles present in the role administration criterion.

The following screenshots illustrate this process.

Create New Criteria - Starting Link

the picture is described in the document text

Create New Criteria - Define the Criteria

the picture is described in the document text

Create Criteria - Select Roles and Privileges and Save

the picture is described in the document text

Update Criteria - Select Criteria to be Updated

the picture is described in the document text

Update Criteria - Populate Roles and Privileges

the picture is described in the document text

Update Criteria - Modify and Save

the picture is described in the document text

Managing System Accounts

UMX formerly supported data security policies for users with a party_id in the TCA schema (HZ_PARTIES table). All such user operations were based on the "User Management Person" Object (UMX_PERSON_OBJECT). As this object was based on the HZ_PARTIES table, it could only manage users linked to a person, or (to put it another way) who had a party_id in the TCA schema. Actions such as "Query Person Details", "Reset Password" , "Edit Person Details", and "Create, Inactivate, or Reactivate Account" on users were dependent on data security policies and permissions granted on the User Management Person Object (UMX_PERSON_OBJECT). Administrators therefore had to create data security policies on the User Management Person Object (UMX_PERSON_OBJECT).

This raised the question of how to administer system accounts, which lack a party_id. UMX had a permission called "Maintain System Account" Permission, which used to maintain all users who lacked party_id. Administrators with this permission could perform all operations on users who lacked a party_id. However, this did not address the issue of how to administer some sets of system accounts with restricted operations.

UMX_SYS_ACCT Object

A data security object called "User Management: system accounts" (UMX_SYS_ACCT) is now provided to support accounts that lack a party_id in the TCA Schema. This "User Management: system accounts" object is based on the database object (table) "FND_USER".

Steps to use UMX_SYS_ACCT

  1. Log on as a user who has been assigned the Security Administrator role (typically as sysadmin), select the User Management responsibility in the navigator, and click the Roles & Role Inheritance sub-tab.

  2. In the role hierarchy, access the role to which you want to assign user administration privileges, and click the Update icon.

  3. Click the Security Wizards button.

  4. Click the Run Wizard icon for "User Management: Security Administration Setup".

  5. Click the User Administration sub-tab, then click on link "Create Instance Set For Users".

  6. Click the Add More Rows button.

  7. In the Users field, select the set of users who can be managed by administrators to whom the role was assigned. The drop-down list contains various data security policies that pertain to the "User Management Person" and "User Management: system accounts" objects. Select the instance set that you created in Step 5.

  8. In the Permissions field, select the permissions that you wish to associate with the delegated administration role.

    If you want to query a user and reset his password, select "Query and Reset Password" permission set in the drop down

  9. Click Apply or Save or to save your changes.

Managing Proxy Users

This section describes how to set up and use the Proxy User feature.

Note: For more information on managing the roles of users, see the section Assigning Roles to or Revoking Roles from Users.

Setting Up Proxy Users

  1. Log in as System Administrator and navigate to User Management > Users.

  2. Query the user (delegator) that you wish to have the ability to grant proxy privileges to other users: click on the Update icon of the results table to navigate to the User Details page.

  3. On the User Details page, click on the Assign Role button, and search for Manage Proxies role in the list of values.

    Pick this role, supply the justification, and click the Apply button.

  4. By assigning the Manage Proxies role to the delegator, you make the delegator eligible to grant proxy privileges to other users to act on the delegator's behalf.

Delegating Proxy User Privileges

  1. As a user with the Manage Proxies role (see previous section), log on to Oracle E-Business Suite and click on the global Preferences menu.

  2. Under the Manage Proxies link, click on the Add People button (see Note below).

  3. Select a user from the list of values, updating the start and end dates if required.

  4. Click on Apply to save the changes.

  5. Once the changes are saved, a notification will be sent to the user who has been granted the proxy privileges.

Note: The permission that controls the list in the Add People LOV is UMX_OBJ_DESIGNATE_PROXY, and the object is UMX_USER_OBJECT. The out-of-the-box instance set contains all the people. The list can be modified by creating a new instance set and a grant (and deleting the existing grant), to restrict the list of people.

Acting as a Proxy User

The proxy user mechanism is employed by users as follows:

  1. If you are a user permitted to act on behalf of other users, you will see your name with the prefix Logged in as in the upper right-hand corner of the page. This reminds you who you are acting as.

  2. To switch to another user (act as a delegate), choose the Switch User icon and link to access the Switch User page. These are only displayed for users who are permitted to use the Proxy User feature.

  3. Click on the Switch User icon to switch to Proxy Mode, where you can act on behalf of the selected user.

  4. The Switch User page shows an alphabetical list of people who have specified that you can act on their behalf, as a delegate.

  5. After you have selected a delegator, the application will enter Proxy Mode. While in this mode, the icon and link will change from Switch User to Return to Self.

  6. The user login information details reflect that you are now acting on behalf of the selected delegator.

  7. While in Proxy Mode, you cannot switch directly to another proxy, but must first switch back to yourself.

  8. To exit Proxy Mode, click on Return to Self.

Running the Proxy User Report

In Proxy Mode, Page Access Tracking (PAT ) is automatically turned on, to audit the pages visited by the user when acting as a proxy for the delegator.

To run a report on proxy user activities, carry out the following steps:

  1. Go to the Preferences > Manage Proxies function.

  2. Click on Run Proxy Report.

  3. Provide the appropriate parameters and run the report.

A concurrent program, Page Access Tracking Data Migration, needs to be run for the proxy to see the most recent updates in the report. Refer to Chapter 5 for details.

Registering External Organization Contacts

Oracle User Management provides a sample registration process that enables administrators to register new people for their organizations. Organizations can use the sample registration process directly or reference it as an example of how to define their own administration registration processes.

Prerequisites

To register new people, an administrator must be assigned the following:

Steps

  1. Log in as a user with a role granting you access to the User Management responsibility, select the User Management responsibility in the navigator and click the Users subtab.

  2. In the Register dropdown list, select administrative account registration process you wish to invoke, and click the Go button.

  3. Enter the information required by the registration process as defined by the registration UI for the registration process, click the Submit button and then click the OK button in the resulting page.

Self Service Features

Implementors and administrators can verify the successful configuration of end user functions by performing the tasks described in this section.

Self-Service Registration

Oracle User Management enables users to register for access to applications without requiring assistance from administrators. To register for application access, users must provide information in the required fields and click the Submit button.

Oracle User Management ships with the following sample self-service registration processes:

Organizations can use these registration processes in their existing form, or can use them as references for developing their own registration processes.

Requesting Additional Application Access

Oracle User Management enables you to request additional access to the specific applications for which you are eligible. Application access is based on roles and to access an application you must be granted the appropriate role. Perform the following to view the roles you have been assigned and to request additional ones.

Steps

  1. After logging into the system, click the Preferences link in the upper right corner, and click the Access Requests link in the sidebar menu. The Access Requests page displays the roles you have been assigned. Click the Request Access button to request one or more additional roles.

  2. Most roles are organized according to role categories: roles that are not categorized appear under the Miscellaneous node. Select the role category that contains the role you want to request. If you do not see the required role, then either you are not eligible for the role or it has not been set up to for additional access requests.

  3. Select the role or roles you require for additional access to the system, and click on the Add to List button. You can optionally remove roles from your list by clicking on the Remove Roles button.

  4. When you have selected all your required roles, click on the Next button.

  5. Enter a justification for your request and click on the Next button. You can remove any pending roles or check their status in the page that appears next.

Guidelines

Some roles may require you to provide additional information. In such cases, the system will prompt you for additional information before you can complete the process for requesting a role.

If the role being assigned would cause a separation of duties violation, the operation will flag this in the workflow attributes, and any approvers for the request will see the details.

Login Assistance

It is not uncommon for system administrators to have to reset a user's forgotten password, or even advise a user of the account's user (login) name. This is unproductive for both the user, who cannot do any work in the meantime, and for the administrator. In addition, a user will occasionally request the password to be reset, when it is actually the user name that has been forgotten, or vice versa. This type of occurrence leads to even more time being lost.

A new feature reduces the time spent in such administrative activities by implementing a login help mechanism that is easily accessed from the E-Business Suite Login Page. A user simply clicks on the "Login Assistance" link located below the Login and Cancel buttons.

On the screen that appears, you can either:

For security, the relevant data is stored securely in workflow tables, and the URLs employed have both an expiration time and a single-use limitation.

The identify verification process required in previous releases of Oracle E-Business Suite is no longer needed. Instead, a link to a secure page is sent to the email address of the user name defined in the system. From this secure page, the user can change password immediately.

Security Reports

The Security Reports feature of UMX enables a security administrator to query the security infrastructure, identifying users who have access to specified security entities and listing the type of access those security entities grant.

Home Page

From the main page of Security Reports, the security administrator can create reports on the basis of “User”, “Role/Responsibility”, “Function/Permission”, or “Data Security Object”. A different set of reports is created for each parameter.

the picture is described in the document text

When creating reports, the security administrator can specify:

In addition, the security administrator can:

For example, a check of offline reports filed by a user might show:

the picture is described in the document text

The following sections describe some the reports that can be produced.

Listing Functions for a User

This report will display assigned functions to a given user. The main record will show:

For each main record there will be a detail row that will show all the paths from which this function is available to the end user, whether it is accessible from that path, and if not, the reason and the date of assignment.

the picture is described in the document text

Filter Conditions

This report has the following filters:

Listing Data Security and Business Objects for a User

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

As the same object could be assigned through multiple paths, all the paths are shown here.

the picture is described in the document text

Filter Conditions

This report has the following filters:

Listing Roles and Responsibilities for a User

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

the picture is described in the document text

Filter Conditions

Listing Users With a Given Role

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

the picture is described in the document text

Filter Conditions

Listing Functions That Can Be Accessed From a Given Role

This report displays assigned functions to a given user. All columns are sortable. The main record will show Function Display Name, Internal Name, Function Type, and Who columns.

the picture is described in the document text

Filter Conditions

Listing Objects for a Given Role

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

As the same function or permission could be assigned through multiple paths, all the paths are shown here.

the picture is described in the document text

Filter Conditions

There are no applicable filter conditions.

Listing Users for a Given Function

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

As the same function or permission could be assigned through multiple paths, all the paths are shown here.

the picture is described in the document text

Filter Conditions

Listing Roles and Responsibilities for a Given Object

The fields listed in the main table for this report are:

The detailed region (Show/Hide) contains the following information:

As the same role or responsibility could be assigned through multiple paths, all the paths are shown here.

the picture is described in the document text

Filter Conditions