, , , ,

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

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 Data Security Policies


With Oracle Applications, organizations can use Data Security to manage permission assignments that control access to objects. Data Security policies can only be defined for applications that have been written to utilize the Data Security Framework. Access to the specific object must be formed with a specified Data Security Policy (also referred to as the Data Scope or Access Policy).
The Data Security Policy restricts operations so that they only can be performed on a subset of instances of the corresponding database object.
Steps
1. Log on as a user with the Functional Developer responsibility, click the Functional Developer responsibility in the navigator, navigate to the Security tab and then click the Objects subtab.
2. Search for and access the object for which you want to create data security policies.
For example, to locate the User Management Person business object (UMX_PERSON_OBJECT), enter “UMX%” in the Code field, click the Go button, and then click User Management Person object (UMX_PERSON_OBJECT) in the
search results list. For any object for which you are creating a policy, ensure that the SQL statement returns the primary key value for that object. In this example, this is a list of person party IDs.
3. Click the Object Instance Sets subtab. Click the Create Instance Set button to create a new object instance set or click the Update icon to modify an existing one.
4. Enter the required information and then click the Apply button.
/by