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:

    • Permissions. Use this tab to assign permissions to your role.

      Delegated Administration Setup Using the Security Wizard

      Information in this section only applies to delegated administration roles in the context of the Oracle User Management application.

      • User Administration. Enables you to determine the set of users that can be managed by administrators to whom your role is assigned. The administrator can assign or revoke user accounts and roles for the users you specify here.

      • Organization Administration. Enables you to determine the external organizations that can be viewed in Oracle User Management by administrators to whom your role is assigned.

      • Role Administration. Enables you to determine which roles the administrator can assign to or revoke from the set of users specified in the User Administration section.

  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 then 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:

    • All Rows. This option provides access to all rows for the database object. For example, if the database object is a book, creating a data security policy for all rows of the object will provide access to all books catalogued in the database.

    • Instance. This option provides access to an instance of the object. A specific instance generally corresponds to a single row in the database, and is typically identified by the primary key value for the object. For example, a data security policy for the book object could contain a unique ISBN number, to return only one book from the database.

    • Instance Set. This option provides access to a related set of instances of the object. This set is specified as a predicate on the attributes of the object. The predicate is expressed as a SQL WHERE clause, and can optionally be implemented as a VPD policy. For example, a data security policy could include an instance set for all books published in the year 2013.

  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 subtab.

  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 list and "Sales Manager" in the text box.

  5. Click on the Go button.

Users Tab

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.

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. For example, you may receive a message that says: "Warning - Updates to Role data will not be visible in the application until the following processes are started: Workflow Background Engine."

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, and then click Roles & Role Inheritance.

  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 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 Window

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 user name. 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.

Additional Information: 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).

Additional Information: 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.

Additional Information: 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

Additional Information: 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

    Additional Information: 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 Attribute 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

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 Provisioning Services.

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:

    • Role. The role with which you optionally associate the registration process and that is assigned to the user at the end of the registration process once the request has been processed.

    • Type. The type of registration process you wish to create.

    • Registration Process Code. The unique identifier for the registration process.

    • Display Name. The display name for the registration process.

    • Description. A description of the registration process.

    • Application. The application with which the registration process is classified. This can be used to help query the registration process.

    • Active From. The date from which the registration process is first active.

    • Active To. The date you can optionally specify to terminate the registration process.

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

    • Registration Start Page. The first page (which is represented as a function) in the registration process that captures any additional user registration information. This is optional unless you are creating a Self Service Account Request registration process.

    • Notification Event. The workflow business event that invokes a workflow. The notification workflow subscribes to the event and subsequently sends notifications to the approver or to the user.

    • Approval Transaction Type. The set of approval routing rules that is interpreted at runtime by the Oracle Approval Management rules engine. The rules determine whether approval is required and by what set of users based on user transaction types you have defined specifically for use with Oracle User Management.

    • Business Event Name. Custom business event that will be raised by Oracle User Management with context information for processing.

  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:

    • Registration Links. Oracle User Management provides support for displaying different registration links on the login page based upon the mid-tier through which the login page is accessed. Organizations can set the server level profile option, "UMX: Register Here Link - Default Registration Process" (UMX_REGISTER_HERE_REG_SRV) to specify different destinations for the registration link.

    • Registration Parameters. The registration link can also contain additional parameters that are not known at design time. These parameters are available at all stages of the registration process; for example, for routing approval requests. You can set the server level profile option "UMX: Register Here Link - Default Registration Parameters" (UMX_REGISTER_HERE_REGPARAMS) for this purpose. The format for setting this profile option is: "ParamName1=ParamValue1&ParamName2=ParamValue2":

    • UI-specific Parameters. Organizations can additionally specify parameters used to control the rendering of the registration user interface, such as the menu displayed in the registration UI. The server level profile option, "UMX: Register Here Link - Default HTML Parameters" (UMX_REGISTER_HERE_HTMLPARAMS) can be set for this purpose. The format for setting this profile option is: "ParamName1=ParamValue1&ParamName2=ParamValue2":

Additional Information: 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 My Oracle Support Knowledge Document 399400.1, Oracle Applications User Management (UMX) Developer's Guide.

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 Apply.

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:

    • Query users

    • Edit personal information

    • Reset password

    • Maintain account information (create, inactivate, reactivate accounts)

    • Maintain system accounts

    • Assign or revoke roles

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. On the Reset Password page, click the Submit button.

The person for whom you reset the password receives an 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

the picture is described in the document text

Define New Criteria

the picture is described in the document text

Select Roles and Privileges

the picture is described in the document text

Update Criteria

the picture is described in the document text

View/Modify Criteria

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 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 the Security Wizards button.

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

  5. Click the User Administration subtab, 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.

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.

Registering User Accounts

From the User Maintenance page under User Management, choose "User Account" from the Register list and click Go to register an Oracle E-Business Suite user. This user is an authorized user of Oracle E-Business Suite, and is uniquely identified by a username.

Once defined, a new Oracle E-Business Suite user can sign on to Oracle E-Business Suite and access data through Oracle E-Business Suite windows.

The Create User Account user interface pages are similar to the Oracle Forms-based Users window.

Note: If you have upgraded from a previous release of Oracle E-Business Suite, ensure that you have run the Party Merge concurrent program to update your user data. If you have not run this program, you may receive errors in querying your user data.

For more information, see the Oracle Trading Community Architecture documentation.

After you have entered the information below, you can click Submit.

Note: This user creation procedure is seeded as registration process "UMX_USER_ACCOUNT_CREATION". This registration process can be updated with the addition of an approval process. A notification will be sent to the approver. When the approver approves, the user is created.

Click the Assign Roles to assign roles and update details for the user.

Account Information

Enter these fields for the user.

User Name

An application user enters this username to sign on to Oracle E-Business Suite.

The username should only contain characters allowed by Oracle Single Sign-On.

Tip: We recommend that you define meaningful usernames, such as the employee's first initial followed by their last name. Or, for a group account, you can define the application username so as to indicate the purpose or nature of the group account.

Active From/To

Enter the date range for which this user account will be active.

The user cannot sign on to Oracle E-Business Suite before the start date or after the end date. The default for the start date is the current date. If you do not enter an end date, the username is valid indefinitely.

You cannot delete an application user from Oracle E-Business Suite because this information helps to provide an audit trail. You can deactivate an Oracle E-Business Suite user at any time by setting the End Date to the current date.

If you wish to reactivate a user, change the End Date to a date after the current date, or clear the End Date field.

Email

Enter the email address for this user.

Fax

Enter the fax number for this user.

Password Expiration

Link to a Party

Use the Person, Supplier, and Customer fields to enter the name of an employee (person), customer, or supplier contact. Enter the last name and first name, separated by a comma, of the employee, customer, or supplier who is using this application username and password. Use the List of Values to select a valid name.

For more information on using these fields, see the Oracle Trading Community Architecture documentation.

Update User

After clicking Assign Roles on the Create User Account page, you can add details for roles, contact information, and securing attributes.

Roles

Click Assign Roles to search for existing roles and assign them to this user. Enter a justification for each role.

Contact Information

If you have chosen to link this user to a party, you can view contact information here. Note that personal information originates from the human resources system and cannot be updated here.

Securing Attributes

Securing attributes are used by some Oracle HTML-based applications to allow rows (records) of data to be visible to specified users or responsibilities based on the specific data (attribute values) contained in the row.

You may assign one or more values for any of the securing attributes assigned to the user. If a securing attribute is assigned to both a responsibility and to a user, but the user does not have a value for that securing attribute, no information is returned for that attribute.

For example, to allow a user in the ADMIN responsibility to see rows containing a CUSTOMER_ID value of 1000, assign the securing attribute of CUSTOMER_ID to the ADMIN responsibility. Then give the user a security attribute CUSTOMER_ID value of 1000.

When the user logs into the Admin responsibility, the only customer data they have access to has a CUSTOMER_ID value of 1000.

Name

Select an attribute you want used to determine which records this user can access. You can select from any of the attributes assigned to the user's responsibility.

Application

The owning application for the attribute.

Value

Enter the value for the attribute you want used to determine which records this user can access.

Reset Password

You can reset a user's password by clicking Reset Password and then Submit. The user will need to change the password upon the next login.

Alternatively, you can reset the password on the main User Maintenance page.

Managing Proxy Users

This section describes how to set up and use the proxy user feature, which allows a user to delegate some of his capabilities to another user.

Note: For an introduction to this feature, see the section: The Proxy User Feature.

Defining Exclusions from Proxy User Delegation

An administrator can exclude certain responsibilities from being allowed to be delegated to proxy users. For example, you may have responsibilities such as "Employee Self-Service" where a user can change personal information and see salary and payslip information. Allowing proxy users access to other users' personal information via such responsibilities may cause privacy and legal issues. It is therefore essential to be able to restrict delegation by proxy users.

Excluded Responsibilities Page

the picture is described in the document text

Steps to Exclude a Responsibility from Being Delegated

  1. Log in as System Administrator and navigate to User Management > Proxy Configuration > Exclusions.

  2. Click the Add Responsibility button.

  3. Select the name of the responsibility you want to exclude from delegation by users.

  4. Click the Apply button.

Making Workflow Item Types Available for Delegation

By default, the list of available workflow item types a user can delegate to a proxy displays those item types for which the user has previously received at least one notification. You can also choose to add item types that you want to appear in the lists for all users. In this way you can allow users to grant a proxy access to handle any notifications they may receive from those item types in the future.

To add an item type to the available list, define the internal name of the item type as a lookup code for the WF: Vacation Rule Item Types lookup type. See: Setting Up Notification Handling Options, Oracle Workflow Administrator's Guide.

Defining Proxy User Delegation Policies

An administrator can set up policies that govern which users delegators can select as their proxy users. Several predefined policies already exist, and you can create additional policies if needed. Creating new policies requires a thorough understanding of creating data security policies and object instance sets, so we recommend using predefined policies if possible.

Proxy Delegation Policies Page

the picture is described in the document text

  1. Log in as System Administrator and navigate to User Management > Proxy Configuration > Policies.

  2. Select the Add button to use one of the predefined policies.

    Search and Select: Add Page

    the picture is described in the document text

    If you want to create your own policy, select the Create & Add Policy button to create a policy specific to your organization.

    Create and Add Policy Window

    the picture is described in the document text

  3. Click the Apply button.

Giving a User Delegation Privileges

There are two ways to give a user privileges to delegate to a proxy user:

  1. Use the Proxy Delegation Privilege page to give delegation privileges to all users, or users of a specific role or responsibility.

  2. Use the User Details page to assign the Manage Proxies role to an individual user. 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.

Assign Delegation Privileges to All Users or Users with a Selected Role or Responsibility

  1. Log in as System Administrator and navigate to User Management > Proxy Configuration > Privileges.

    Proxy Delegation Privilege Page

    the picture is described in the document text

  2. If you want to give delegation privileges to all users, select the All Users option. If you want to give delegation privileges to users of a specific role or responsibility, select the Users with the Selected Roles or Responsibilities option, and then choose the role or responsibility you want.

  3. Click the Apply button.

Assign the Manage Proxies Role to an Individual User

  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.

Delegating to a Proxy User

Once a user has delegation privileges, either by proxy user privileges configuration or by being given the Manage Proxies role directly, that user (the delegator) can then delegate other users as proxy users. For example, an employee going on vacation might want to designate her manager as a proxy user during her absence.

  1. As a user with the delegation privileges, log on to Oracle E-Business Suite and click on the global Settings menu.

    Settings Menu on the Oracle E-Business Suite Home Page

    the picture is described in the document text

  2. Select Manage Proxies to navigate to the Proxy Configuration page, where you can see and update any existing proxies.

  3. Click the Add Proxy button to add a new proxy user to work on your behalf.

    Proxy Configuration Page

    the picture is described in the document text

  4. On the Add People page, select a user from the list of values, updating the start and end dates if required. You can also enter notes that will be displayed in the notification that your proxy user will receive to advise that he has been designated as a proxy.

    Add People Page

    the picture is described in the document text

  5. In the Grant Responsibility Access section, you can select None, Selected, or All responsibilities to delegate to your proxy user. If you choose the Selected option, you can then select any responsibilities from the Available Responsibilities list that you want your proxy user to access, and move them over to the Selected Responsibilities list. You may not see all of your responsibilities in the Available Responsibilities list if some have been excluded from delegation by your administrator. Your proxy user will see only the responsibilities you select here when working on your behalf.

    Grant Responsibility Access Section

    the picture is described in the document text

  6. In the Grant Worklist Access section, you can select None, Selected, or All Workflow item types to delegate to your proxy user. If you choose the Selected option, you can then select any workflow item types from the Available Item Types list that you want your proxy user to access, and move them over to the Selected Item Types. By default, the Available Item Types list displays those item types for which you have previously received at least one notification. Your administrator can also add item types to this list to let you grant your proxy user access to handle other notifications you may receive in the future. Your proxy user will see only the selected workflow item types when working on your behalf.

    Grant Worklist Access Section

    the picture is described in the document text

  7. Click Apply to save the changes.

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

Acting as a Proxy User

If you are a user designated to act on behalf of another user (the delegator), you may initially receive a notification that you have been designated as a proxy user for the delegator, though receiving the notification is not required (and some organizations do not use Oracle Workflow).

  1. If you are a user permitted to act on behalf of other users, you will see the Switch User link or icon in the page header. Select the Switch User link or icon.

    Oracle E-Business Suite Page Header Switch User Icon

    the picture is described in the document text

  2. You will see your own user name with the prefix "Logged In As" in the upper corner of the page.

  3. To switch to another user (act as a delegate), choose the Switch User icon or link to access the Switch User page.

    Switch User Page

    the picture is described in the document text

  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. Click on the icon in the Switch column to switch to Proxy Mode, where you can act on behalf of the selected user.

  6. After you have selected a delegator, the application enters Proxy Mode. While you are working as a proxy user, you will see your name and the name of the user for whom you are acting as proxy. You will not see the Favorites or Settings choices in the header, nor will you see the Navigator's Top Ten List for Oracle Forms-based forms. While you are in proxy mode, the link changes from Switch User to Return to Self, though the icon remains the same.

  7. For most pages, you will see a notice near the top of the page that says "Proxy For" with the user name of the delegator, indicating that you are acting as a proxy user for that delegator.

    Proxy User Oracle E-Business Suite Home Page

    the picture is described in the document text

    If you are using a form built with Oracle Forms, you will see a notice at the very top of the window showing that you are acting as a proxy user.

    Proxy Oracle Forms Window

    the picture is described in the document text

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

  9. Perform your tasks as the proxy.

    For more information about handling another user's workflow notifications while acting as a proxy, see: Worklist Access, Oracle Workflow User's Guide.

  10. To exit Proxy Mode, return to the Home page and click on Return to Self (the Switch User icon).

Note: If you are permitted to act as a proxy user for multiple delegators, you cannot switch directly from one to another. You must Return to Self first.

Running the Proxy User Report

In Proxy Mode, Page Access Tracking (PAT) is automatically turned on to track the pages visited by the proxy user when acting on behalf of the delegator.

A concurrent program, Page Access Tracking Data Migration, needs to be run for the delegator to see the most recent updates in the report. The administrator must run this report.

To see a report on your proxy user's activities, perform the following steps as the delegator:

  1. Choose the Settings > Manage Proxies function.

  2. Select Run Proxy Report.

  3. Specify the proxy user whose actions you want to review, the responsibility with which the proxy user performed the actions, and the start and end dates for the date range during which the proxy user performed the actions. Then run the report.

    Proxy Report Page

    the picture is described in the document text

Running the Proxy Audit Data Report

Administrators can run a report to review Audit Trail data for actions performed by a proxy user for any delegator user. To make the proxy audit data available, you must first set up Audit Trail and run the Audit Trail Update Tables Report. See: Steps to Enable Audit Trail.

To run the proxy audit data report, you must log in as a user with the FND_PROXY_AUDIT permission. This permission is granted to the SYSADMIN user by default. An administrator can optionally grant it to other users.

To run the proxy audit data report, perform the following steps:

  1. Choose the Settings > Manage Proxies function.

  2. Select Run Proxy Audit Data Report.

  3. Specify the database object you want to review, the delegator user, and the proxy user whose actions you want to review. Optionally specify the start and end dates for the date range during which the proxy user performed the actions. Then run the report.

    Proxy Audit Report Page

    the picture is described in the document text

  4. The Proxy Audit Report page submits a concurrent request for the audit report and displays the request ID. Choose the report status link to navigate to the Requests page. From this page, you can check the report status, view the report output, and optionally republish the report.

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 Oracle 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.

Security Reports Page

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:

Offline Report Status Page

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.

List of Functions Report

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.

List of Objects Report

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:

List of Roles Report

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:

List of Users of a Given Role Report

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.

List of Functions Accessed from a Given Role Report

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.

List of Objects for a Given Role Report

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.

List of Users for a Given Function Report

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.

List of Roles/Responsibilities for a Given Object Report

the picture is described in the document text

Filter Conditions