, , , , ,

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

Defining a Responsibility in R12


When you define a responsibility, you assign to it some or all of the components described below.
1. Menu (Required)
A menu is a hierarchical arrangement of application functions (forms). In the definition of a responsibility, the specified menu defines what is displayed in the navigator. The specified menu does not necessarily define the functions that can be accessed by the responsibility, which are granted.
2. Data Group (Required)
A data group defines the mapping between Oracle Applications products and ORACLE database IDs. A data group determines which Oracle database accounts a responsibility’s forms, concurrent programs, and reports connect to.
Oracle Application Framework functionality does not support data groups.
For almost all cases, you should accept the default value in defining a responsibility.
3. Function and Menu Exclusions (Optional)
A responsibility may optionally have function and menu exclusion rules associated with it to restrict the application functionality enabled for that responsibility
4. Responsibilities and Request Security Groups
Note: The Request Security Groups feature is for backward compatibility only.
When a request group is assigned to a responsibility, it becomes a request security group.
From a standard submission form, such as the Submit Requests form, the choice of concurrent programs and request sets to run are those in the user’s responsibility’s request security group.  If you do not include the Submit Requests form on the menu for a responsibility, then you do not need to assign a request security group to the responsibility.
Responsibilities and Function Security
Oracle Applications architecture may aggregate several related business functions into a single form. Parts of an application’s functionality may be identified as individual Oracle Applications functions, which can then be secured (i.e. included or excluded from a responsibility).

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

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