Implementing Oracle User Management

<Course name> <Lesson number> - 1

Schedule: Timing Topic90 minutes Lecture90 minutes Labs and Guided Demonstrations180 minutes Total


Steps for Implementing Oracle User ManagementFor the purposes of this course, Phase I: Define Core Security Features has already been completed, and students will begin with Phase II: Define Roles. When implementing Oracle User Management, however, you must begin by defining core security features.You do not have to implement User Management in the exact sequence described here. However, this is probably the most common implementation flow.You will test many of the implementation steps by logging on as an administrator or as a user, and viewing the results of your configuration.


Configuring and Testing Oracle User ManagementSystem AdministratorAs system administrator (security administrator), you define roles, role inheritance hierarchies, delegated administration, registration processes and self-service features. You also designate local administrators and assign them roles, and optionally allow them to perform self-service registration. Depending on how those roles are configured, local administrators manage a subset of the organization’s users and roles, as well as designated external contact information.Local AdministratorsAs a local administrator, you test the delegated administration features defined for the role you are assigned. These features enable you to manage a subset of your organization’s users and roles, and to manage designated external contact information. End UsersAs an end user, you test the available self-service features such as requesting access (or additional access) to the system.


Introduction to RolesIn previous releases of Oracle Applications, access to individual functions within an application could only be defined through responsibilities, menu hierarchies, and menu exclusions. New responsibilities had to be defined for each set of users (with different job functions) that needed access to a set of pages within an application. These responsibilities required either:

• Completely new menu hierarchies for each responsibility• A common menu covering the superset of all functions within the application, and menu

exclusion rules defined for each responsibilityAn example is the Human Resources product, which typically has at least two responsibilities defined, one for employees and one for managers.In essence, responsibilities have been used not only to define the application navigation menus, but also the privileges and permissions within an application. Cost of ownership and management has increased with the number of responsibilities, as multiple complex menu hierarchies and/or exclusion rules must be maintained.Oracle User Management provides new alternatives for defining access to an application, allowing organizations to separate navigation menus from access control.


Examples of RolesIn this example, the manager is granted both the employee role and the manager role, since the manager effectively functions as both.


Defining Roles: Data Security PoliciesData security policies determine what data users can access, and return only that set of data to those users at runtime. ExampleData security policies determine to which department a manager belongs, and returns only the correct set of data for that manager. In the above example, the Manager role is assigned to Managers X and Y. At runtime, data security policies determine that Manager X should only view Department X data, and Manager Y should only view Department Y data.


Defining Roles: Assigning a Single Responsibility that Includes all Functions to a RoleOrganizations can define a single responsibility that includes all functions and assign it to a role. For example, instead of having a Manager Expenses and Employee Expenses responsibility, an organization can define an Expenses responsibility that contains all employee and manager Expenses functions. The grant flag is turned off for all menus defined for this role.


Defining Roles: Assigning a Single Responsibility to a Role with Some Functions Included

When a role is assigned, the relevant user is granted the appropriate functions. For example, the employee is granted employee expenses functions, but the manager expenses functions remain excluded.


Defining Roles: Assigning Responsibilities to a RoleOrganizations can define multiple responsibilities for a single role. With the grant flag on for all menus in the menu tree, assigning the role to a user gives that user access to all the menus defined for the role.In this example, the Manager Expenses and Employee Expenses responsibilities are defined for the Manager role. When the Manager role is assigned to the manager, the manager has access to all functions defined for these responsibilities.


Role Inheritance HierarchiesOracle User Management enables you to link roles together in 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 its sub-roles.Role inheritance means that the permission to access a new page only has to be granted once, at the lowest-level sub-role in the role inheritance hierarchy; the relevant permissions will then be inherited automatically by all superior roles in the hierarchy. Equally, revoking access to a page (or an entire application) is as simple as granting access.ExampleIn this example some roles such as "Employee" or "Manager" are assigned general permissions for a given function. For example, the Employee role may provide access to menus generally available to all employees, while the Manager role provides access to menus that should only be viewed by managers. Because the Employee role is a sub-role of the Manager role, anyone assigned the Manager role automatically obtains the permissions associated with the Employee role. Other roles in this example pertain to more specific job functions, such as Sales Manager or Sales Representative.


Assigning Permissions to RolesYou can configure permissions for a role.

• Data Security: You must select a business object when you create Data Security policies. Specifying the object data context (data scope) provides an additional level of access granularity for the object. Choose one of the following from the Data Context menu:

- All Rows: Provides access to all rows (instances) for the database object.- Instance: Provides access to an instance (single row in the database) of the object. - Instance Set: 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.

• Activation Context: Restricts the availability of the permissions being assigned. If you do not define the activation (security) context, permissions are available to users in all contexts.

- Operating Unit: Many organizations consist of several different operating units. You can limit your grant to be active only in the context of an individual operating unit.

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


Advantage of Roles Over ResponsibilitiesA role can be associated with multiple responsibilitiesBecause a single role can be associate with multiple responsibilities, multiple responsibilities can be assigned to a single role, then assigned to users as required. This is more efficient than assigning or revoking individual responsibilities to each user. When updating menu access or permissions, organizations can simply add new menu items to the responsibility with the grant flag off, then switch the grant flag on for a role if the role needs to have access to that menu.Roles can inherit the properties of other rolesWith role inheritance hierarchies, roles can inherit the permissions of roles. This simplifies the process of defining roles: when defining a higher-level role such as ‘manager’, there is no need to include access to employee menus and responsibilities, since these are inherited from the lower-level ‘employee’ role.Navigation menus and security functions can be separatedAs noted in the introduction to this section, RBAC and role inheritance allows organizations to separate navigation menus from access control: a responsibility can be defined to represent a single application, and a menu can be tailored for each application. Access to the application (responsibility) and its menu hierarchy are controlled by different roles, each representing a specific job function or set of people.


Steps for Creating Roles: Define a Role CategoryIn this scenario, an organization is creating a Customer Administrator role. It will require a role category to contain this or similar roles.

Instructor NoteRefer to the Guided Demonstrations and Practices manual for hands-on exercise(s) on this topic.


Steps for Creating Roles: Create a Role within the Role CategoryCreate a role and include it within the role category. In this scenario, the role is Customer Administrator. This role is created for an external organization, and is assigned to individuals who manage the external organization’s users.Oracle User Management ships with three seeded roles, Partner Administrator, Customer Administrator, and Security Administrator. The business scenarios and practices in this course assume that the Customer Administrator role must be created and configured to function with the other two.Note: Many of the practices in this course involve creating, configuring, and testing the Customer Administrator role. Since Oracle User Management already ships with this role, the practices require students to create a Course Administrator role that is essentially an exact copy of the seeded Customer Administrator role. Students can compare their Course Administrator role to the seeded Customer Administrator role; the two should be identical.


Steps for Creating Roles: Place Role in Role Inheritance HierarchyPlace the Customer Administrator role in a role inheritance hierarchy. In this case, the ‘Partner Administrator’ role inherits permissions from the ‘Customer Administrator’ role, and from the User Management Responsibility.



Steps for Creating Roles: Assigning Permissions to RolesYou can use roles to enable or disable the permissions that the ‘Customer Administrator’ role inherits from the ‘User Management’ responsibility. In this example, ‘User Maintenance UIs’ is the only permission enabled for the ‘Customer Administrator’ role when it inherits the ‘User Management’ responsibility. As a result, when an individual who is assigned the ‘Customer Administrator’ role logs on to the system, that person will be able to access ‘User Maintenance UIs’, but not be able to query users unless assigned user administration privileges.



Steps for Creating Roles: Assign Role to a New PersonThe system administrator creates a new person and assigns the Customer Administrator Role to that user.


Steps for Creating Roles: Test Role as Customer AdministratorLog on as the newly created Customer Administrator (person assigned the Customer Administrator role) and test your capabilities.


User Administration PrivilegesTo grant a local administrator user administration privileges, you must configure the role assigned to the local administrator. When configuring the role, you must choose which of the available people and users you want the local administrator to manage, and which permissions you want to grant the role for managing those people and users.People and UsersPeople are any individuals in the system; users are those individuals for whom an account has been created.PermissionsPermissions determine the actions that the role assignee (the local administrator) can perform on the people and users selected for that role. These permissions must be granted with a data security policy on the User Management Person (UMX_PERSON_OBJECT) business object.


Configuring Roles for User AdministrationLocal administrators can be granted different privileges for different subsets (groups) 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. ExampleIn this example, assignees of the Local Administrator Role can manage two subsets of their organization’s users and people, Subset A and Subset B. They have permissions to query and edit person details, manage user accounts, and reset passwords for all users of Subset A. However, they can only query person details for all users of Subset B.


Role Administration PrivilegesA role can specify a subset of roles that the assignee can manage. To grant a local administrator role administration privileges, you must configure the role assigned to the local administrator.When configuring the role, you must choose which of the available roles in the system you want the local administrator to manage. There is a single seeded permission available for defining role administration privileges for roles, which has a function code of UMX_OBJ_ADMIN_ROLE. To enable role administration, this permission must be granted with a data security policy on the User Management Role (UMX_ACCESS_ROLE) business object.


Seeded Permissions for User AdministrationAll user administration privileges must be granted with a data security policy on the User Management Person (UMX_PERSON_OBJECT) business object. The Query Person Details (UMX_OBJ_VIEW_PERSON) permission is the minimum permission required by any security administrator who wishes to manage people and users in Oracle User Management. The Maintain System Accounts (UMX_SYSTEM_ACCT_ADMINSTRATION ) permission is only granted to system administrators.


Managing Roles with Role AdministrationIn this example, the local administrator can assign roles to (or revoke roles from) the users in Subsets (groups) A and B.


Seeded Permissions for Role AdministrationAll role administration privileges must be granted with a data security policy on the User Management Role (UMX_ACCESS_ROLE) business object.


Organization Administration PrivilegesThis privilege enables local administrators 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 the administration account registration process has been granted, the administrator may have the ability to register new people for that organization.


Seeded Permissions for Organization Administration PrivilegesAll role administration privileges must be granted with a data security policy on the User Management Organization (UMX_OBJ_VIEW_RLTNSHPS) business object.


Advantages of Delegated Administration Over Traditional System AdministrationWith traditional system administration, one or more trusted individuals manage access control and users for the entire organization. The system administrator must assign access privileges to a potentially large number of people and users.With delegated administration, local administrators manage a specific subset of the organization’s users and roles. Because they can only assign a specific set of roles to a specific set of users, local administrators ensure that security is maintained along functional areas. Generally, local administrators will have a working relationship with the set of users they manage.


Set Up User Administration for a RoleThe system administrator sets up user administration for the Customer Administrator role by determining the users it enables the assignee to manage and the manner (permissions) in which those users can be managed.


Registration ProcessesOracle User Management contains the following registration processes:Self-Service Account RequestsCommonly referred to as Self-Service Registration, self-service account requests provide a means for people to request a new user account. For example, customers may need to register before they can purchase an item from an online store. After completing the registration process, the customer obtains both a user account and the necessary role(s) to access the store.Requests for Additional AccessUsers can request additional access through the Oracle User Management Access Request Tool (ART), available on the global preferences menu. Requests for Additional Access uses the same Oracle User Management infrastructure and processing logic as Self-Service Account Requests.Account Creation By AdministratorsAdministrators can benefit from existing registration processes designed to streamline the process of creating and maintaining user access. Registration Processes of this type are geared toward administrators, especially delegated administrators, to ensure consistent application of the client's user security policies. Each account creation registration process can be made available to select administrators.


Registration Process Core ComponentsRoles are assigned after the user successfully completes the registration process:

• The registration user interface is optional, and is used for collecting account or additional information.

• The workflow is used for approval, confirmation, rejection, and identity verification notifications.

• The approval management transaction type represents a set of approval routing rules that are interpreted at runtime.

• The set of users eligible to request additional access are only applicable for the Request for Additional Access registration processes.

• Identity verification confirms the identity of a requester before the registration request is processed. An email notification is sent to the submitting email address. If the recipient does not reply within a predetermined amount of time, the request will be automatically rejected.

The set of local administrators should be able to register people and/or create users through the Account Creation by Administrators registration process.


Self-Service Account RequestsSelf-service account requests provide a method for persons to request a new user account. Recall the earlier example where customers need to register before they can purchase an item from an online store: after completing the registration process, the customer obtains both a user account and the necessary role(s) for access to the store.Accounts and user accounts (person party in TCA) in this course refer to an individual's login account, stored in the FND_USER table.This release of Oracle User Management provides sample Self-Service registration UIs for internal employees and for new, external individuals. Organizations can copy these sample Self-Service registration and extend them based on their own requirements. In addition, organizations wishing to support other types of users, or capture additional user information, can create their own registration UIs and business logic.


Requests for Additional AccessWhen users request additional access to the system, they are in effect making a request to be granted additional roles. The availability of additional roles depends on the user’s current roles. For example, an organization’s employees could request roles that further define their job functions, while customers of that organization would not be able to request those same roles. For example, an employee could request the ‘Support Rep’ role, but a customer could not.


Account Creation by AdministratorsEach account creation registration process can be made available to selected administrators.


Steps for Creating Registration ProcessesThe following slides describe the steps in the creation of registration processes.


Steps for Creating Registration Processes: Provide Required Description InformationThe System Administrator creates the request for additional access registration process and assigns it to one of the roles managed by the Customer Administrator. The Customer Administrator subsequently logs on and assigns that role to a new user.You must provide the following information for the registration process description:

• Role: The role with which you optionally associate the registration process, and which is assigned to the user at the end of the registration process.

• Type: Type of registration process you wish to create.• Registration Process Code. Unique identifier for the registration process.• Display Name: Display name for the registration process.• Description: Description of the registration process.• Application: Application with which the registration process is classified, which can be used for

querying the registration process.• Active From: Date from which the registration process is first active.• Active To: Date you can (optionally) specify to terminate the registration process.


Steps for Creating Registration Processes: Enter Runtime Execution InformationEnter the runtime execution information for the registration process and click the Next button. This information specifies:

• Registration Start Page: The first page (represented as a function) in the registration process, which captures any additional user registration information. This page 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. Based on the user transaction types you have defined specifically for use with Oracle User Management, the rules determine whether approval is required, and if so, by which set of users.


Steps for Creating Registration Processes: Enter Eligibility InformationEnter the eligibility information for the registration process by selecting the appropriate roles or groups. In this case, eligibility will be everyone. For 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 which administrators can register new users through the registration process. Oracle User Management ships with the following seeded permissions for defining eligibility policies:Administrator Assisted Account Creation (UMX_OBJ_ADMIN_CRTN_FLOW )Permission representing "Administrator Assisted Account Creation" registration processes. Must be granted as a data security policy on the Registration Process (UMX_REG_SRVC) business object. Self-Service Eligibility (UMX_OBJ_ROLE_ELGBLTY)Permission representing registration processes for additional access determines the set of end users who are eligible to register for a given role/registration process. Must be granted as a data security policy on the Registration Process (UMX_REG_SRVC) business object.


Steps for Creating Registration Processes: Register Subscriptions to Business EventsRegister subscriptions to the appropriate business events raised by Oracle User Management, ensuring that your subscription logic writes the registration data to the appropriate destination schemas.


Steps for Creating Registration Processes: Optionally Set Profile OptionsOptionally 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 application 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. Organizations can set the server level profile option, “UMX: Register Here Link: Default Registration Parameters” (UMX_REGISTER_HERE_REGPARAMS) for this. The format for 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. The format for this profile option is: "ParamName1=ParamValue1&ParamName2=ParamValue2“.


Steps for Creating Registration Processes: Optionally Set Login Page UI AttributesOptionally set the UI attributes for the login page using the profile option, Local Login Mask: FND_SSO_LOCAL_LOGIN_MASK. For the Login page to display one or more of these optional attributes, add the numeric values of all desired attributes and set the value of the profile option to that value:

• USERNAME_HINT = 01• PASSWORD_HINT = 02• CANCEL_BUTTON = 04• FORGOT_PASSWORD_URL = 08• REGISTER_URL = 16• LANGUAGE_IMAGES = 32 • SARBANES_OXLEY_TEXT = 64

For example, to show PASSWORD_HINT and FORGOT_PASSWORD_URL only, set the profile option to 10 (02+08). To show just the LANGUAGE_IMAGES set the value to 32, which is the default.



Steps for Creating Registration Processes: Test as Customer AdministratorThe Customer Administrator assigns the role associated with the registration process to a customer. The customer can then request additional access. You perform this test in Phase IV: Understand and Test the Self-Service Features.


Managing Proxy UsersProxy users are set up by logging in as System Administrator, navigating to User Management > Users, querying the user (delegator) who is to grant proxy privileges to other users, clicking on the Update icon of the results table to navigate to the User Details page, clicking on the Assign Role button, searching for Manage Proxies role in the list of values, and selecting this role.Proxy User privileges are delegated by logging on as a user with the Manage Proxies role, clicking on the Global Preferences menu, clicking on the Add People button under the Manage Proxies link, and selecting a user from the list of values. Once the changes have been saved, a notification is sent to the user who has been granted the proxy privileges.Acting as a Proxy User

• Users permitted to act on behalf of other users will have their names displayed with the prefix Logged in as in the upper right of the page.

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

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

Using Proxy Mode turns on Page Access Tracking, to enable auditing of pages visited by the user when acting as a proxy. Go to Preferences > Manage Proxies > Run Proxy Report


Login AssistanceSystem administrators often 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 and the administrator. In addition, a user may request the password to be reset, when it is actually the user name that has been forgotten, or vice versa.A new feature in Release 12 helps reduce the time spent on such administrative activities, by implementing a login help mechanism on the E-Business Suite Login Page. A user simply clicks on the "Login Assistance" link located below the Login and Cancel buttons.On the login assistance screen that appears, the user can either go to the Forgot Password section and enter the correct user name, or to the Forgot Username section and enter the email address associated with the account. The user will then either be emailed either password reset details or the user name, as applicable.For security, the relevant data is stored securely in workflow tables, and the secure URLs employed by the mechanism have both an expiration time and a single-use limitation.

Implementing Oracle User Management

Documents

Transcript of Implementing Oracle User Management