, , , , ,

Function Security

Function security is the mechanism by which user access to applications functionality is controlled.
Function security can be considered as “global data security”, in that it grants access to a function regardless of the current row of data. Oracle Applications architecture aggregates several related business functions into a single form. Because all users should not have access to every business function in a form, Oracle Applications provides the ability to identify pieces of  applications logic as functions. When part of an application’s functionality is identified as a function, it can be secured (i.e., included or excluded from a responsibility).
Application developers register functions when they develop forms. A System Administrator administers function security by creating responsibilities that include or exclude particular functions.
Function
A function is a part of an application’s functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility. There are two types of functions: executable functions (formerly called form functions), and non-executable functions (formerly called subfunctions).
Executable Function
Executable functions have the unique property that you may navigate to them using the Navigate window.

Non-executable Function
A non-executable function) is a securable subset of a form’s functionality: in other words, a function executed from within a form.
A developer can write a form to test the availability of a particular non-executable function, and then take some action based on whether the non-executable function is available in the current responsibility.
Non-executable functions are frequently associated with buttons or other graphical elements on forms. For example, when a non-executable function is enabled, the corresponding button is enabled.
However, a non-executable function may be tested and executed at any time during a form’s operation, and it need not have an explicit user interface impact. For example, if a non-executable function corresponds to a form procedure not associated with a graphical element, its availability is not obvious to the form’s user.
Menu
A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it.
Menus can map to permission sets as well.
Menu Entry
A menu entry is a menu component that identifies a function or a menu of functions. In some cases, both a function and a menu of functions correspond to the same menu entry. For example, both a form and its menu of subfunctions can occupy the same menu entry
Responsibility
A responsibility defines an application user’s current privileges while working with Oracle Applications. When an application user signs on, they select a responsibility that grants certain privileges, specifically:

  • The functions that the user may access. Functions are determined by the menu assigned to the responsibility.
  • The concurrent programs, such as reports, that the user may run.
  • The application database accounts that forms, concurrent programs, and reports connect to.
/by
, , , , ,

Case Sensitivity in Oracle Applications User Passwords


Case Sensitivity in Oracle Applications User Passwords In previous releases of Oracle Applications, user passwords were treated as case insensitive. Now, Oracle Applications user passwords can optionally be treated as case sensitive, depending on the mode you choose.
Case-sensitivity in passwords is controlled by the site-level profile option Signon Password Case. This profile has two possible settings:

Sensitive – Passwords are stored and compared as they are, with the password case preserved. During comparison, if the entered password does not match the decrypted version, then an error message is displayed. With Release 12, this option is the default behavior. All newly created or changed passwords are treated as case sensitive.
Note: Users who have not changed their passwords since the installation of release 12 are not affected until they do change their passwords.
A password expiration utility is available if the System Administrator requires that all users convert to case sensitive passwords upon the next login. This utility expires all passwords in FND_USER, including that of SYSADMIN and default Vision accounts, and can be run as a SQL Script ($FND_TOP/sql/AFCPEXPIRE.sql) or as a Concurrent Program (FNDCPEXPIRE_SQLPLUS).
Insensitive (or unset) – Passwords are treated as case insensitive. In Insensitive mode, passwords are stored and compared in uppercase, similar to that in earlier releases. The entered password and the decrypted password are converted to uppercase prior to comparison.
If you want to preserve case insensitivity in passwords, i.e. retain the behavior from previous releases, ensure that Signon Password Case value is either set to ‘Insensitive’, or not set at all.
There are no upgrade or data migration issues with this new feature. The profile option affects only how new passwords are stored. Existing passwords are tested using the policy in effect when they were created.
/by
, , , , ,

Oracle Application Object Library Security


As System Administrator, you define Oracle Applications users, and assign one or more responsibilities to each user.
Defining Application Users
You allow a new user to sign-on to Oracle Applications by defining an application user. An application user has a username and a password. You define an initial password, then the first time the application user signs on, they must enter a new (secret) password.
When you define an application user, you assign to the user one or more responsibilities.
Responsibilities Define a User’s Context
A responsibility provides a context in which a user operates. This context can include profile option values, navigation menus, available concurrent programs, and so on.
For example, a responsibility can allow access to:

  • A restricted list of windows that a user can navigate to; for example, a responsibility may allow certain Oracle Planning users to enter forecast items, but not enter master demand schedule items.
  • A restricted list of functions a user can perform. For example, two responsibilities may have access to the same window, but one responsibility’s window may have additional function buttons that the other responsibility’s window does not have.
  • Reports in a specific application; as system administrator, you can assign groups of reports to one or more responsibilities, so the responsibility a user choose determines the reports that can be submitted.

Each user has at least one or more responsibilities, and multiple users can share the same responsibility. A system administrator can assign users any of the standard responsibilities provided with Oracle Applications, or create new custom responsibilities if required.
HRMS Security
The Human Resources Management Systems (HRMS) products have an additional feature using Security Groups.

/by
, , , , ,

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

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.
  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.
  8.  Click Save or Apply to save your changes.
Navigate back to the user tab to assign the new role to any existing user.
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.
 
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.
Defining Organization Administration Privileges for Organizations

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.
/by
, , , , ,

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