, , , , ,

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

Steps
1. Create roles representing the required job functions such as Manager and Employee.
2. Define a role inheritance hierarchy.
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 previous releases of Oracle Applications, 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:
• A completely new menu hierarchy for each responsibility, or
• A common menu covering the superset of all functions within the application, and menu exclusion rules defined for each responsibility.
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.
1.  Administration and changes can be accomplished with minimal effort:

  • A new page only has to be added to a single menu.
  • The permission to access a new page, only has to be granted once to the lowest level (subordinate role) in the role inheritance hierarchy.
  • An entirely new application (responsibility) can automatically be assigned to a set of people by simply defining it as the subordinate role of an existing role.
  • Permissions to access the various pages and functions within a new application should only be assigned at the lowest level in the role inheritance hierarchy.
  • The permissions are then automatically inherited by all superior roles in the hierarchy.
  •  Revoking access to a page, or an entire application, can be accomplished as
    easily as adding access.

2.  Improved end user experience. In the applications navigator, end users will see a list of applications to which they have access. Access to the various functions within each application is determined by the roles assigned to the end user.
Steps
1. Define a new responsibility that will be used to represent a specific application such as Expenses or Human Resources.
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.
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.

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.
5. Define role inheritance relationships. 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:

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

/by
, , , , ,

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:

  1. Self Service Account Requests
  2. Self-Service Requests for Additional Access
  3. Account Creation by Administrators
  4. Administrator Assisted Request for Additional Access

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.
4. Enter the runtime execution information for the registration process and click the Next button.
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
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.

/by
, , , , ,

Creating USER and User Name Policy


An user id should be created for each employee who needs access to the system. After an employee is created in HRMS, SYSADMIN logins to User Management and search for that employee by first and last name.
The sysadmin needs to enter the mail id and password (not mandatory, if not entered manually system generates a password). A mail is sent to the user with the log in credentials. Next the sysadmin can add the roles/responsibilities to the user as per the business requirements.

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

Administrators can configure either of these seeded policies. In addition to these, custom policies can also be implemented if desired.
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 racle.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
In all the three of the stages above, the values set must correspond to the same user name policy.
The Listener and JVMs must be restarted after the user name policy is changed.

/by
, , , , ,

OUM Setup and Administration


The implementor or system administrator sets up access control and security policies in Oracle Applications 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 Applications 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.
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.
The newly created Role Category can be verified in Roles & Responsibilities of Roles & Role Heritance Tab.
Creating and Updating Roles

In Oracle Applications, 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.
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.
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.
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:
4.1. Enter the required information to identify the grant, such as Name and Effective From date.
4.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.
4.2.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.
4.2.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.
4.2.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 2005.
/by
, , , , ,

Proxy Users in Sys Admin


There are a number of business scenarios in which users of Oracle E-Business Suite need to grant delegates the ability to act on their behalf (act as proxy users for them) when performing specific E-Business Suite functions. Traditionally, delegators have done this by giving passwords for specific applications to other users. A delegate who
was given another user’s passwords for certain applications could assume the identity and privileges of the delegator within those applications, and only those applications.
The integration of E-Business Suite with Oracle Application Server 10g Single Sign-On (SSO) makes this traditional strategy insecure. If a delegator grants a delegate access to his SSO password, the delegate will be able to access every SSO-enabled application to which the delegator has access, not just to specific applications. The new mechanism was designed to enable limited, auditable delegation of privilege from delegators to their delegates.
Important: Employing the Proxy User mechanism gives all-or-nothing delegation capability. However, start and end dates can be defined to limit the duration of proxy access.
Examples of Delegation
There are a number of common scenarios where a user may need to allow another user or users to interact with the E-Business Suite on their behalf:

  1. Executives allowing their assistants to access selected business applications on their behalf
  2. In a similar way to executives and their assistants, but for a more limited duration, managers may need to grant peers or subordinates limited authority to act on their behalf while they are out of the office
  3. Users may need to grant help-desk staff limited duration access to their E-Business Suite accounts, so that help desk staff can investigate problems and provide assistance
  4. The Proxy User mechanism allows such users to obtain limited, auditable access to accounts such as SYSADMIN that might otherwise have to be shared and therefore harder to audit
  5. Companies may be subject to audits that require granting a specific user (the auditor) access to employees’ E-Business Suite accounts, normally on a read-only basis.

The ability for users to access the proxy feature is controlled by a Security Administrator role. Users with this role determine which set of users can create delegates who can act on their behalf.
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, log on to Oracle Applications and click on the global Preferences menu.
2. Under the Manage Proxies link, click on the Add People button.
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.

/by