, , , , , ,

User Session in R12

Using the following profile options you can specify limits on user sessions.
ICX:Session Timeout
Use this profile option to enforce an inactivity time-out. If a user performs no Oracle Applications operation for a time period longer than the time-out value (specified in minutes), the user’s session is disabled. The user is provided an opportunity to re-authenticate and re-enable a timed-out session. If re-authentication is successful, the session is re-enabled and no work is lost. Otherwise, Oracle Applications exits without saving pending work.
If this profile option to 0 or NULL, then user sessions will never time out due to inactivity.
ICX: Limit time
Use this profile option to specify the absolute maximum length of time (in hours) of any user session, active or inactive.


/by
, , , , , ,

Objects in AOL


Data Security uses the concept of an Object to define the data records that are secured.
Object
Data security permissions are managed on objects. Business entities such as Projects and Users are examples of objects. Only a securable business-level concept should be registered as an object. An object definition includes the business name of the object and identifies the main table and primary key columns used to access the object.
Object Instance
An object instance is a specific example of an object, such as Project Number 123 or User JDOE. An object instance generally corresponds to a row in the database. An instance is identified by a set of one or more primary key values as defined by the object. In addition, “All Rows” for an object indicates all data rows of the object.
Users and Groups
Users and groups are Oracle Workflow roles. See the Oracle Workflow documentation for more information on roles.
Privileges given to users and groups determine their access to secured objects.
The data security system allows you to assign privileges to groups of users instead of assigning privileges to each user individually.
Users
Users are individuals who have access to software applications at a particular enterprise. A user must have a unique name and should map one-to-one with an individual human or system. “Group” accounts are not correct uses of the user entity.
Groups
Users can belong to Groups. The grouping can come from position or organization relationships modeled in applications such as Oracle Human Resources. Alternatively, ad-hoc groups can be created explicitly for security purposes. A group is sometimes referred to as a role.

Creating Objects

Use these pages to find, create, and edit data objects. You define objects to be secured in the Data Security system. Objects can be tables or views. An object must be queryable in SQL, and the combination of primary key columns specified must be a unique key.
In these pages, objects are described with the following

  • The Name is the name that appears in the Object Instance Set and Grants pages. This name should be user-friendly.
  • The Code is the internal name of the object.
  • The Application Name is the owning application.
  • The Database Object Name is the name of the underlying database object
/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