Fundamentals of System Administration

Fundamentals of System
Administration
Overview
Copyright © 2007, Oracle. All rights reserved.
Fundamentals of System Administration 510946395.doc

Effective Paradigm_effective Page 1 of 50 Rev Paradigm_revision
Fundamentals of System Administration
System References
None
Distribution
Job Title*
Ownership
The Job Title [[email protected]?Subject=EDUxxxxx] is responsible for ensuring that
this document is necessary and that it reflects actual practice.

Fundamentals of System Administration

Course Objectives

Introduction to Application Security

Successive Layers of Access Control
Successive Layers of Access Control

Access Control with Oracle User Management is implemented in successive layers and each
layer builds upon the one that precedes it. Organizations can, optionally, uptake the various
layers depending on the degree of automation and scalability they wish to build upon the
existing Function and Data Security models.
There are six layers of access control. The Core Security layers include:
• Function Security
• Data Security
The next four layers are part of Oracle User Management:
• Role-Based Access Control
• Delegated Administration
• Registration Processes
• Self Service and Approvals

Increasing Flexibility and Scalability
Increasing Flexibility and Scalability

In general, access control with Oracle User Management (OUM) begins with basic system
administration tasks, and then progresses to more distributed, local modes of administration,
ultimately enabling users to perform some basic, predefined registration tasks on their own.
Details of the various levels of access control, and the increasing level of flexibility and
automation that they provide are provided later in the lesson. However, the following general
guidelines may be considered for now:
System Administrator
Oracle’s Function Security and Data Security mechanisms constitute the base layers of the
security system, and contain the traditional system administrative capabilities. Organizations
can, optionally, add more layers to the system depending on the degree of flexibility they want.
By themselves, Function Security and Data Security limit the scope of OUM to basic system
administration by granting access to specific menus and to the data accessed from within those
menus.

Local Administrators
When Role-Based Access Control and Delegated Administration are added to the Data
Security and Function Security layers, system administration tasks can be distributed to local
administrators who manage a subset of the organization’s users.
End Users
Registration Processes and Self Service and Approvals distribute system administration further
by automating some registration tasks so that end users can perform them.

Self Service and Approvals
Self Service and Approvals

After the registration processes have been configured as per requirements, individuals can
subsequently perform self-service registration tasks, such as obtaining new user accounts or
requesting additional access to the system. In addition, organizations can use the Oracle
Approvals Management engine to create customized approval routing for these requests.
Example
An organization may enable users to request a particularly sensitive role. However, before the
user is granted the role, the organization can specify that two approvers, a manager and a vice
president, must provide their approval.

Function Security

Function Security
Function Security
Function Security restricts user access to individual menus of functions, such as forms, HTML
pages, or widgets within an application. It allows you to define a user and assign the user one
or more responsibilities, with each responsibility having a menu associated with it. Function
Security, by itself, restricts access to various functions, but it does not restrict access to the data
that a user can see or the actions that a user can perform on the data.
This lesson discusses the definition of users, responsibilities, and menus.

Application Security: Overview
Application Security: Overview

In an Oracle Application, the System Administrator manages security by creating user sign-ons
and assigning them to one or more responsibilities. Users then have access to all the
functionalities associated with that responsibility.
User Security
You authorize a user to sign-on to Oracle Applications by defining an application user with one
or more responsibilities assigned.
Responsibility Security
A responsibility is a collection of authorizations that allow access to:
• A specific application or applications
• A Ledger
• A restricted list of windows, functions, and reports
Each user has one or more responsibilities, and several 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 as required.

Self-Service Applications Security
Oracle Self-Service Web Applications use columns, rows, and values in database tables to
define the information that users can access. Table columns represent “attributes” assigned to a
responsibility. These attributes are defined in the Web Application Dictionary.
Responsibility
A responsibility is a collection of authorizations allowing access to:
• A specific application or applications
• A Ledger
• A restricted list of windows, functions, and reports. These may be associated to the
responsibility through menus.
Each user has one or more responsibilities, and several 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 as required.
Users
A user is defined as a human being. Although the concept of a user can be extended to include
machines, networks, or intelligent autonomous agents, the definition is limited to a person in
this document. You authorize a user to sign-on to Oracle Applications by defining an
application user with one or more responsibilities assigned.

Defining an Application
Defining an Application
(N) Application > Register
You can protect custom functions, forms, reports, and programs from being lost during
upgrades by registering them.
In the Applications Window, you will supply the following information:
• Application: Enter a user-friendly name that will appear in the lists seen by the user.
• Short Name: Oracle Applications uses this short name to identify forms, menus,
concurrent programs, and other components of your application.
• Base Path: Enter the base path to the location of the forms, reports, and program files.
Make sure your base path is unique to prevent other applications from writing to the same
directory.
For a complete explanation of the fields in this Form, see:
(Help) Applied Technology > Oracle Applications System Administration > Applications DBA
> Applications Window

Defining Data Groups
Defining Data Groups

A data group is a collection of pairings of an application with an Oracle ID. Data groups
automatically support concurrent processing and cross-application reporting. They guarantee
that an application connects to a unique application database account.
Note: The installation process automatically defines data groups for Oracle Applications.
Application-Oracle ID Pairs
• An application can be listed only once in a data group.
• An Oracle ID can be paired with more than one application.
• A custom application registered with Oracle Applications can be included in a data group.
Data Groups and Application Object Library
Application Object Library (AOL) owns the database tables referred to during concurrent
processing and the standard submission of reports by any Oracle Application. Therefore all
applications need access to the AOL tables. When you are defining a data group, the
application AOL is automatically included and cannot be updated or deleted.

Relating Data Groups to Forms and Programs
You can control the relationship among applications, forms, and concurrent programs by
defining a data group.
Applications, Forms, and Programs
• A window connects to the application database account designated by the responsibility
associated with the application.
• A data group determines the pairing of an application with a unique application database
account or Oracle ID.
• A program connects to the application database account associated with the application
that owns the program.
Application-Oracle ID Pairs
• An Oracle ID is a username and password that allows access to application tables in an
Oracle database.
• A data group lists the Oracle ID assigned to each Oracle application.
• A custom application registered with Oracle Applications can be included in a data group
and paired with an Oracle ID.

Use of Menu and Function Security to Modify Responsibilities

Importance of Responsibilities
Importance of Responsibilities
Each application user is assigned at least one responsibility. A responsibility determines
whether the user accesses Oracle Applications, Self-Service Web Applications, or Mobile
Applications. In addition, a responsibility determines the application functions that a user can
use, the reports and concurrent programs that the user can run, and the data that those reports
and concurrent programs can access.

Components of a Responsibility
Components of a Responsibility
Required Components
• Data group: A data group specifies the Oracle Application database accounts to which a
responsibility’s forms and concurrent programs connect.
• Menu: A menu specifies the forms that a responsibility can display and the functions it can
access.
Optional Components
• Request group: A request group lists the concurrent programs that a responsibility can
run. When a request group is assigned to a responsibility, it is referred to as a request
security group. You can limit the list of reports available (providing only a subset) to a
group of users by creating a request group and assigning it to a responsibility. Request
groups can include:
- All the reports and concurrent programs that a user can run
- Individual concurrent requests
- Request sets
- Stage functions

• Exclusions: Exclusions modify a responsibility’s access to the forms and functions
specified by a menu.

Defining a New Responsibility
Defining a New Responsibility

• Assemble the components of application privileges to create a responsibility.
• Define the responsibility by assembling a menu, report security group, and data group, and
defining any function security (any menu or function exclusions).
You must assign the following to your new responsibility:
• A data group to supply the form, report, and program connect privileges
• A menu to supply access to forms within an application
You can assign the following:
• Any function or menu exclusions to control access to the functionality of the application
• A report security group to control access to reports and concurrent programs
(N) Security > Responsibility > Define
A responsibility determines whether the user accesses Oracle Applications or Oracle Self-
Service Web Applications, the application functions that a user can use, the reports and
concurrent programs that the user can run, and the data that those reports and concurrent
programs can access.

Defining a New Application User
Defining a New Application User

(N) Security > User > Define
Note: All Navigation paths, unless otherwise specified, are from the System Administrator
Responsibility.
Though defining user accounts may be the last task you complete while setting up function
security for your installation, we will cover this task first in order for you to complete the
following sections by logging in to Oracle Applications with your own user account.
Define an authorized user of Oracle Applications by specifying a username and password.
Grant application privileges by assigning one or more responsibilities to the user. The user will
be able to access functions and reports via the assigned responsibilities.
For a complete explanation of the fields on the Users Form, see:
(Help) Applied Technology > Oracle Applications System Administration > Overview of
Oracle Applications Security > Users Window

Assigning Responsibilities to Users
Assigning Responsibilities to Users

Generally, you relate new application users to predefined responsibilities. However, you can
customize an existing responsibility or create new responsibilities to accommodate the needs of
different users or different categories of users. When creating a new responsibility, it is
generally easier to modify an existing responsibility in one of the two ways:
Extend the Privileges That a Responsibility Owns
• When users require additional reporting and summary information, you can:
- Use request groups to add additional program or report privileges to a responsibility
- Use menus to add windows and tasks to a responsibility
Restrict the Privileges That a Responsibility Owns
• Sometimes, it is easier to remove authorizations from an existing responsibility.
- Use exclusions against a responsibility to limit menu and function access privileges to
those required for job duties.
- Use request groups to limit program or report privileges for a responsibility requiring
only data entry privileges.
After you have defined a new responsibility, you can associate it with an application user.

Refer to Practice - Creating a New User (Required) [LAB42B4Y]

Managing Function Security
Managing Function Security

You can manage security by controlling access to individual functions through menu
definitions.
About Functions
• A function is a set of code in Oracle Applications that is executed only if the name of the
function is present in a list maintained on a responsibility-by-responsibility basis.
• There are two types of functions: a form function or form, and a non-form function or
subfunction. A subfunction represents a securable subset of a form’s functionality.
Adding Functions to or Removing Functions from a Responsibility
• Maintain menu structures while eliminating a specific functionality.
• Exclude individual functions from a responsibility.
Adding or Removing Menus of Functions
• Group functions together using menus.
• Exclude groups of functions by excluding a menu from a responsibility.

Menu Displays in the Navigator
Menu Displays in the Navigator

The Navigator displays only those menu items that are required for navigation. Because you
cannot choose subfunctions from a menu, they are not displayed. Submenus consisting of only
subfunctions are also not displayed.

Excluding Functions and Menus
Excluding Functions and Menus

Use exclusion rules to configure a responsibility. You can exclude functions at any level.
• When you exclude a menu item from a responsibility, all menus and functions nested in
menu are also excluded.
• When you exclude a function from a responsibility, all occurrences of that function
throughout the responsibility’s menu structure are excluded.
A “full access” responsibility with a menu that includes all the functions in an application is
predefined for each Oracle Applications product. Some applications may provide additional
predefined responsibilities that include a smaller set of functions (that is, fewer forms and
subfunctions).
As a System Administrator, you can restrict the functionality a responsibility provides by
defining rules to exclude specific functions or menus of functions. In fact, we recommend that
you use exclusion rules to customize a responsibility in preference to constructing a new menu
hierarchy for that responsibility.
For example, suppose you want to customize a responsibility to restrict the functionality of a
form included in that responsibility. First, you examine the predefined menus that group the

subfunctions associated with that form. Then, using exclusion rules, you can restrict the form’s
functionality by excluding some of the form’s subfunctions from the responsibility.
Refer to Guided Demonstration - Creating a Responsibility by Using Menu Exclusions
(Optional) [LAB42B6Y]

Data Security

Data Security
Data Security
• Data Security is the next layer and builds on Function Security. It provides additional
access control on the data that a user can access, and the actions that a user can perform on
that data, within Oracle Applications.
• Restricts access to the individual data that is displayed on the window after the user has
selected a menu or menu option.
Data Security is not implemented in all the Oracle Applications products. Some applications
may require organizations to create multiple responsibilities to operate with their existing
security models. Working in conjunction with Function Security, Data Security provides
additional access control on the data that a user can see and the actions that a user can perform
on that data. Using Data Security, for example, you can control access to the set of orders that
an administrator can update within the Order Management application.
Data Security Policies restrict the actions or operations that can be performed on a specific
business object (for example, inventory items). Data Security Policies can reflect access to:
• All Instances: All instances of an object represents all rows in the database table or view.
For example, assume that we have an object, “inventory item,” in the database. Creating a

Data Security Policy for all instances of the object would result in providing access to
every single inventory item that we have catalogued in the database.
• An Instance Set: An instance set is a related set of instances of an object. This corresponds
to a set of rows in the database. Using our object example, an instance set could be
constructed to include all inventory items with a shelf life of seven days.
• A Specific Instance: A specific instance generally corresponds to a single row in the
database, and is generally identified by a primary key value for the object. Using our
example, we could enter a unique serial number for the inventory item. This would return
one and only one inventory item from the database.

Data Security Components: Objects
Data Security Components: Objects

(N) Functional Developer responsibility > Objects
An object is a system entity on which an operation can be performed.
In Oracle Applications, an object typically maps to records in relational tables or views, Forms
or HTML pages, and UI widgets. Examples in Oracle Applications include: a person, a
machine, and a file.
Examples of operations include: Create, Update, Escalate, Approve, and Reject. In Oracle
Applications, operations are implied by a permission definition. Permission is defined as an
operation on an object—for example, Invoke Service Request Form, Update Order, Approve
Expense Report, and Query Customers.
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, and is identified by a
set of one or more primary key values as defined by the object. Related object instances can be
grouped together into an object instance set.
System Administrators control various profile options in Oracle Applications that determine
how the applications look, feel, and operate.

Grants
Grants
(N) Functional Administrator Responsibility > Grants
Grants are used to provide specified users access to specific objects or functions.
Grants that deal with business objects are called Data Security Policies.
Grants can also be used to control access to an application’s functionality. For example, you
can use a grant to secure an aspect of a menu, page, or other widget within the application. For
example, you want to provide access to a set of administrative menus to a select group of users.
The grantee defines who is being granted access. The grantee can be one of three types:
• A group of users
• A specific user—for example, Joe Smith
• All users (global)—this applies to all users of the system, except the Guest account

Permissions and Permission Sets
Permissions and Permission Sets

The Role-Based Access Control (RBAC) model defines permission as “an approval to perform
an operation on one or more RBAC-protected objects.” This definition maps to what has been
referred to as functions earlier. Permissions can be grouped into permission sets.
Permission sets can be granted to users or roles independent of menus or responsibilities.
Permission assignments, or Grants, reflect the access granted to users through roles.

Set Profile Options

Set Profile Options
Set Profile Options

System Administrators control various profile options in Oracle Applications that determine
how the applications look, feel, and operate. In this lesson, you learn how to specify the profile
option values.

Profile Hierarchy Types
Profile Hierarchy Types

Of the three hierarchy types, the Security type is the most widely used one.

Profile Hierarchy Levels: Security
Profile Hierarchy Levels: Security

You can set user profiles at different levels by using one of the three hierarchies.
Most profile options use the Security hierarchy, in which setting a user profile affects
application users across one of the four different levels.
• Site Level: Site-level settings apply to all users at an installation site. To display the name
of your installation site, select About Oracle Applications from the Help menu.
• Application Level: Application-level settings apply to all users of the specified
application. For example, a profile could be set that applies to all Oracle General Ledger
users. Profile options that can be set at the application-level override options set at the site
level.
• Responsibility Level: Responsibility-level settings apply to all users currently signed in
under the responsibility. For example, a profile could be set that applies to all users of the
Oracle General Ledger GL budget supervisor responsibility. Profile options that can be set
at the responsibility level override options set at the site and application levels.
• User Level: User-level settings apply to individual users, identified by their application
usernames. For example, a user profile could be set that applies only to user JDoe. Profile
options set at the user level override all other options.

Profile Hierarchy Levels: Organization
Profile Hierarchy Levels: Organization

The second hierarchy type is Organization, where organization refers to an Operating Unit. For
example, clerks in different organizations may need to have different values for a given profile
option, depending on their organization, but clerks in the same organization would use the
same value.
The Organization hierarchy type allows System Administrators to set a profile option at the
organization level, so that all users within that organization will use the profile option value set
once at the organization level.
Profiles using the Organization type use the hierarchy Site - Organization – User, where a user-
level option overrides the organization-level option, which, in turn, overrides the site-level
option.

Profile Hierarchy Levels: Server
Profile Hierarchy Levels: Server

The Server hierarchy type is used when the system needs to determine the server on which the
user’s session is running. For example, the profile “Applications Web Agent” can be defined
using the Server hierarchy type. The setting of this profile option can differ for an internal
server and an external one. Cookie validation, for example, can then be done against the value
of this profile option.
Profiles using the Server type use the hierarchy Site - Server - User, where a user-level option
overrides the server-level option, which, in turn, overrides the site-level option.

Personal Profile Values
Personal Profile Values

For further information about using the Personal Profile Values Window, see:
(M)(Help) >Oracle Applications Library > (T) Contents >User’s Guide >
Getting Started – Demo > Introduction > User Profile Options
The FND_PROFILE_OPTION_VALUES table stores values for user profile options. Each row
includes values that identify the profile option; the profile level; and the user, responsibility,
application, organization, server, or site for which the profile value is set. There is one row for
each profile option setting (at each level, for each user, and so on).

System Profile Options
System Profile Options

For profiles using the Security hierarchy type, if you choose to set a value at the application,
responsibility, or user level, you must also specify the particular application, responsibility, or
user. Any values defined at a level lower than the level chosen will also be displayed.
Likewise, for profiles using the Organization hierarchy, if you choose to set a value at the
organization or user level, you must also specify the particular organization or user.
For profiles using the Server hierarchy type, if you choose to set a value at the server or user
level, you must also specify the particular server or user. Any values defined at a level lower
than the level chosen will also be displayed. Of the three hierarchy types, such as Security,
Organization and Server, the Security type is the most widely used one.
For a complete description of the fields in the System Profile Values Window, see:
(Help) Applied Technology > Oracle Applications System Administration >Setting Profile
Options > System Profile Values Window

Profile Categories
Profile Categories
(N) Functional Administrator responsibility > Core Services > Profile Categories
Profile options can be grouped into logical categories based on their functional areas and can
be associated with more than one category.
You can create new or update existing profile categories.
The following slides describe some of the more commonly used profile options. However, they
do not represent all the profile options included in each listed profile category.
Refer to Guided Demonstration – Setting Profile Options (Optional) [LAB42B5Y]

Standard Request Submission

Concurrent Processing
Concurrent Processing
Concurrent processing helps you satisfy the following business needs:
• You can continue working on your computer while running data-dependent reports and
programs.
• You can fully use the capacity of your hardware by executing many application tasks at
the same time.
You can run a non-interactive, data-dependent function, such as a report or a program,
simultaneously with online operations. With concurrent processing, you can complete non-
interactive tasks without interfering with the interactive work performed in your terminal.
An example of concurrent processing occurs when you use the Post Journals Window in your
Oracle General Ledger application. After you specify the journal batches to post and click Post,
your Oracle General Ledger application uses concurrent processing to post the journal batch
entries without further involvement from you. Meanwhile, your terminal is still available for
you to continue doing other work in Oracle Applications.
Oracle Applications runs all of its reports and programs as concurrent processes whether you
submit them using the Submit Requests Window, or using a product-specific submission
window. Your System Administrator can tailor concurrent processing to optimize the

performance of Oracle Applications to ensure that the system is not overloaded with processing
at any time.


Standard Request Submission (SRS) allows you to satisfy a related set of business needs. You
can:
• Use a standard interface to run your programs and reports
• View report output online
• Automatically run programs, reports, or request sets at specific time intervals
• View a log file that summarizes the completion information about all the reports and
programs in a request set
Use of Standard Request Submission gives you control over how you can run your requests
and request sets.
There are three elements involved in submitting a request:
• Selecting the request or request set to be submitted
• Defining a submission schedule
• Providing completion options

Submitting a Request
Submitting a Request
1. Navigate to the Submit a New Request Window.
2. Select the Single Request option to submit single requests, or choose to submit a
predefined group of requests by selecting the Request Set option.
3. Click OK.
4. Use the Copy button to take advantage of previously entered request submissions. Or,
select the Name of the request (report or program) to run from the list of available
requests.
Note: Your responsibility determines the request group, which, in turn, determines the list
of requests available to you.
5. A Parameter Window automatically appears when a request requiring parameter values is
selected. The prompts in the Parameters Window are specific to the request that you
select.

6. Enter the values in the required parameter fields and click OK. The Parameters Window
closes, and your parameter values are concatenated and displayed in the Parameters
Window.
7. Click the Submit button to submit the request.
Instructor Note
Refer to Practice: Running Reports and Programs covered in Navigation lesson to relate the
SRS topic to the students.

Summary


Fundamentals of System Administration

Uploaded by

Copyright:

Available Formats

Fundamentals of System Administration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentals of System Administration

Uploaded by

Copyright:

Available Formats

Fundamentals of System

Copyright © 2007, Oracle. All rights reserved.