, , , , ,

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

Delegated Administration Tasks


The Delegated Administration layer of Access Control in Oracle Applications 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.
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, such as a Guest
account, that are not linked to people.
Typically, people and users are managed by local administrators, who can perform the following tasks:

  • Register new people (optional: requires access to have been granted to the “Account Creation by Administrators” registration process)
  • Create, update, or disable user accounts
  • Reset passwords
  • Grant users access to different parts of the system by assigning or revoking roles
Common Prerequisites

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

  1. A role that is granted the User Maintenance UIs (UMX_USER_ADMIN_UI_PERMS) permission set. The role must also inherit the User Management responsibility.
  2. Appropriate privileges for User Administration, Role Administration, and Organization Administration.
  3. The Query Person Details (UMX_PERSON_OBJECT) permission for the set of people and administrator can manage.
  4. Optionally, the Edit Person Details (UMX_OBJECT_EDIT_PERSON) permission for the set of people that the administrator can manage.
  5. For system administrators, the Maintain System Accounts (UMX_SYSTEM_ACCOUNT_ADMINISTRATION) permission.

 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
The important roles that you need to assign to any user with administrator responsibility are

  • System Administration
  • CRM HTML Administration
  • System Administrator
  • Security Administrator : Security Administrators manage all user accounts in the system, and  can assign / revoke all roles. Security Administrators also manage system accounts (such as   GUEST), that are not tied to a person. 
  • System Administrator :  Application Object Library System Adminstrator
  • User Management
/by
, , , , ,

Access Control with Oracle User Management


In Release 12 Core Security includes Oracle’s Function and Data Security models, as well as Role Based Access Control. Administrative Features build upon Core Security and include Delegated Administration, Registration Processes, and Self Service and Approvals.
Core Security and Administrative Features are implemented in successive layers and each builds upon the one that precedes it. Organizations can optionally uptake the various layers, depending on the degree of automation and scalability that they wish to build upon the existing Function and Data Security models.
In general, Access Control with Oracle User Management begins with basic system administration tasks, progresses to more distributed, local modes of administration, and ultimately enables users to perform some basic, predefined registration tasks on their own. The above diagram illustrates how the layers build upon each other.
Function Security
Function Security is the base layer of access control in Oracle Applications. It restricts user access to individual menus and menu options within the system, but does not restrict access to the data contained within those menus. For example, an organization could use Function Security to provide its sales representatives with the required
menus and menu options for querying customers. It could also control access to specific components of those pages such as a button on a sales forecasting page
Data Security
Data Security is the next layer of access control. Building on Function Security, Data Security provides access control within Oracle Applications on the data a user can access, and the actions a user can perform on that data. Oracle Applications restricts access to individual data that is displayed on the screen once the user has selected a menu or menu option. For example, Data Security restricts the set of users that a local administrator can access within Oracle User Management. Data Security policies can only be defined for applications that have been written to utilize the Data Security Framework.
Role Based Access Control (RBAC)
RBAC is the next layer and builds upon Data Security and Function Security. With RBAC, access control is defined through roles, and user access to Applications is determined by the roles granted to the user. Access control in Oracle Applications closely follows the RBAC ANSI standard (ANSI INCITS 359-2004) originally proposed by the National Institute of Standards & Technology (NIST), which defines a role as “a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.”
A role can be configured to consolidate the responsibilities, permissions, function security and data security polices that users require to perform a specific function. This is accomplished with a one-time setup, in which permissions, responsibilities, and other roles are assigned to the role. Users are not required to be assigned the lower-level
permissions directly, since permissions are implicitly inherited on the basis of the roles assigned to the user. This simplifies mass updates of user permissions, since an organization need only change the permissions or role inheritance hierarchy defined for a given role, and the users assigned that role will inherit the new set of permissions
automatically.
Role Inheritance Hierarchies
Roles can be included in role inheritance hierarchies that can contain multiple subordinate roles and superior roles. With role inheritance hierarchies, a superior role inherits all of the properties of its subordinate role, as well as any of that role’s own subordinate roles. The following example demonstrates how role inheritance hierarchies can greatly simplify user access control and administration.


 
Delegated Administration
Delegated Administration is a privilege model that builds on the RBAC system to provide organizations with the ability to assign the required access rights for managing roles and user accounts. With delegated administration, instead of relying on a central administrator to manage all its users, an organization can create local administrators and grant them sufficient privileges to manage a specific subset of the organization’s users and roles. This provides organizations with a tighter, more granular level of security, and the ability to easily scale their administrative capabilities. For example, organizations could internally designate administrators at division or even department
levels, and then delegate administration of external users to people within those (external) organizations. Delegation policies are defined as data security policies. The set of data policies that are defined as part of delegated administration are known as Administration Privileges.

Delegating to Proxy Users
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 delegate
Provisioning Services
Provisioning services are modeled as registration processes that enable end users to perform some of their own registration tasks, such as requesting new accounts or additional access to the system. They also provide administrators with a faster and more efficient method of creating new user accounts, as well as assigning roles.
Registration processes accomplish this by encapsulating core components of registration, including:

  • The role(s) assigned after the user successfully completes the process.
  • An optional registration user interface for collecting account or additional information.
  • A workflow for approval, confirmation, rejection, and identity verification notifications.
  • The Approval Management Transaction Type. A transaction type represents a set of approval routing rules that are interpreted at runtime.
  • The set of users that are eligible to sign up for additional access (only applicable for Request for Additional Access registration processes).
  • Whether identity verification is required. Identity verification confirms the identity of a requester before the registration request is processed, by sending an email notification to the requester’s email address. If the recipient does not reply within a specified time, the request will be automatically rejected.
  • The set of local administrators that should be able to register people and/or create users through the Account Creation by Administrators registration process.

When a user completes registration using a registration process, the system captures the required information from the user, and subsequently assigns that person a new user account, role, or both. Oracle User Management supports three types of registration processes: Self-service Account Requests, Requests for Additional Access, and Account Creation by Administrators.

/by
, , , , ,

System Administrator – Security


Release 12 of Oracle Applications provides significant enhancements to the Oracle Applications security system. Core Security now includes a Role Based Access Control model that builds on the existing Function Security and Data Security models. A new set of administrative features that build on Core Security are also introduced in this release.
Oracle User Management
Oracle User Management is a secure and scalable system that enables organizations to define administrative functions and manage users based on specific requirements such as job role or geographic location. With Oracle User Management, instead of exclusively relying on a centralized administrator to manage all its users, an  organization can create local administrators and grant them sufficient privileges to manage a specific subset of
the organization’s users. This provides the organization with a more granular level of security, and the ability to make the most effective use of its administrative capabilities.
Oracle’s function and data security models constitute the base layers of this system, and contain the traditional system administrative capabilities. Organizations can optionally add more layers to the system, depending on the degree of flexibility they require.
Key features of Oracle User Management include:
Role Based Access Control (RBAC) – Enables organizations to create roles based on specific job functions, and to assign these roles the appropriate permissions. With RBAC, administrative privileges and user access are determined by assigning individuals the appropriate roles.
Delegated Administration – Enables system administrators to delegate some of their administrative privileges to individuals that manage a subset of the organization’s users. These individuals are assigned administrative privileges for a limited set of roles that they can assign to the users they manage.
Registration Processes – Enable organizations to provide end-users with a method for requesting various levels of access to the system, based on their eligibility. Registration processes also simplify an administrator’s job by providing streamlined flows for account maintenance and role assignment.
Self Service Requests and Approvals – Enable end users to request initial access or additional access to the system.
Oracle Application Object Library Security
Oracle Application Object Library security comprises two main components, Function Security and Data Security.
Function Security restricts user access to individual menus of functions, such as forms, HTML pages, or widgets within an application. Function Security by itself restricts access to various functions, but it does not restrict access to the data a user can see or what actions a user can perform on that data.
Data Security restricts the access to the individual data that is shown once a user has selected a menu or menu option. For example, with Data Security you can control the set of users that a particular local security administrator can access within Oracle User Management. In conjunction with Function Security, Data Security provides additional
access control on data that a user can see or actions a user can perform on that data.
User and Data Auditing
Oracle Applications allows you to audit users and changes they make to application data.
The Sign-On Audit feature allows you to track your users’ activities. You can choose who to audit and what type of user information to track. Sign-On Audit reports give you historical, detailed information on your users’ activities within an application. Also, the Monitor Users form allows you to view online, real-time information on user activity.
AuditTrail lets you keep a history of changes to important data: what changed, who changed it, and when. With AuditTrail, you can easily determine how any data row or element obtained its current value. You can track information on most types of fields, including character, number, and date fields.
Security Administrators manage all user accounts in the system, and can assign / revoke all roles. Security Administrators also manage system accounts (such as GUEST), that are not tied to a person.
/by