, , , , ,

How Function Security Works

Executable functions are selected using the Navigate window. The arrangement of form names in the Navigate window is defined by the menu structure assigned to the current responsibility.
The following types of menu entries are not displayed by the Navigate window:

  • Non-executable functions
  • Menus without Entries
  • Menu Entries without a Prompt

If none of the entries on a menu are displayed by the Navigate window, the menu itself is not displayed.

Menu Entries with a Submenu and Functions
If a menu entry has both a submenu and a function defined on the same line, then the behavior depends on whether or not the function is executable. If it is executable, then the submenu on the same line is treated as content to be rendered by the function. The submenu will not appear on a navigation tree, but will be available in function security
tests (FND_FUNCTION.TEST calls). If the function is not executable, then it is treated as a “tag” for enforcing exclusion rules, and the submenu on the same line is displayed in the navigation tree.
A function is considered executable if it can be executed directly from the current running user interface. For example, an Oracle Applications form using Oracle Forms is an executable function from within Oracle Forms, but not within the Self Service applications.
Registering Functions
• Developers can require parts of their Oracle Forms code to look up a unique function name, and then take some action based on whether the function is available in the current responsibility. Function names are unique.
• Developers can register functions. They can also register parameters that pass values to a function. For example, a form may support data entry only when a function parameter is passed to it.
Warning: In general, you should not modify names, parameters, or other material features of predefined functions for Oracle Applications products. The few exceptions are documented in the  relevant manuals or product notes.
Excluding Functions
Each Oracle Applications product is delivered with one or more predefined menu hierarchies. System Administrators can assign a predefined menu hierarchy to a responsibility. To tailor a responsibility, System Administrators exclude functions or menus of functions from that responsibility using exclusion rules.
Note: The ability to exclude functions is to be used for backward compatibility only. Menu exclusions do not apply to grants.
Available Functions for a User
Functions are available to a user through responsibilities (as well as grants).
When a user first selects or changes their responsibility, a list of functions obtained from the responsibility’s menu structure is cached in memory.
Functions a System Administrator has excluded from the current responsibility are marked as unavailable.
Executable functions in the function hierarchy (i.e. menu hierarchy) are displayed in the Navigate window. Available non-executable functions are accessed by working with the application’s forms.
Menu Compilation
The Compile Security (FNDSCMPI) concurrent program is used to compile menus so that the system can more quickly check if a particular function is available to a particular responsibility/menu.
You should compile your menus after you make changes to your menu data. A request for this concurrent program is automatically submitted after you make changes using the Menus form.

/by
, , , , ,

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