Details

Multi-Org Access Control

'Multi-Org Access Control' (also known as 'MOAC' in short form) is an enhanced feature of
Release 12. MOAC enables users to access secured data in multiple operating units from a single
responsibility. End-Users can access/transact data within several operating units based on a
Security Profile attached to the responsibility.

This Provides flexibility for end-users to work conveniently with multiple operating units in
shared service environments with a single responsibility
MOAC and Security Profile
In the Multiple Organization Architecture, data in application tables is secured by operating unit
(ORG_ID).

In releases 10.7 and 11.5.X, the profile option 'MO: Operating Unit' assigned to a responsibility,
restricted data access for that responsibility to a single operating unit. To transact data in multiple
operating units, multiple responsibilities were required, one for each operating unit we needed to
access. The application tables were accessed via Multi-Org views which filtered the data limiting
access to the single operating unit assigned to your responsibility.

From R12 onwards, the profile option 'MO: Security Profile' enables access to multiple operating
units from single responsibility. MOAC enabled forms allow end-users to select an operating
unit and then process transactions in that operating unit. The list of operating units accessible to
the end-user from a single responsibility is determined by 'Security Profile' defined at
responsibility or user level via the profile option 'MO: Security Profile'.

The 'Security Profile' concept was introduced in Release 11i Oracle Human Resources
Management as a means for assigning and restricting access to different organizations (Please
refer to Oracle Human Resources Management Systems Configuring, Reporting, and System
Administration Guide Release 11i). MOAC leverages security profiles to determine which
operating units a user or responsibility has access to.

In the database, synonyms secured by 'Fine-Grained Access Control' are used to filter data for a
single operating unit. These synonyms replace the Multi-Org views restricted by
CLIENT_INFO(Org Context) which were used in 11i.

Configuring MOAC
The setup steps required to make use of MOAC features after upgrading to R12.X are:

- Define Operating Units(Optional) (Using form function 'Define Organizations')
Define Security Profiles (Using form function 'Define Global Security Profile')

Enter a unique name for the security profile.
To restrict access by discrete list of organizations, select 'Secure organizations by
organization hierarchy and/or organization list for the Security Type'.
Check the Exclude Business Group check box to remove the business group in the list
of organizations.
Use the Classification field to limit the list of values (LOV) in the Organization Name
field. For example, if you select the classification to Operating Unit, only
operating units will display in the LOV.
In the organization name field, select the Operating Unit for which you want access.
Repeat until you have included all organizations to which you need access.
Run the concurrent program "Security List Maintenance Program" from the standard request
submission form. The "Security List Maintenance Program" can be run for a single
named security profile to prevent impact to other security profiles.
Assign appropriate security to the profile option "MO: Security Profile" for your users and
responsibilities
Navigate to the "System Administrator" responsibility > System Profile Options
Assign the security profiles to MO: Security Profile for your responsibilities and/or
users.
Assign a value for profile option "MO: Default Operating Unit" (Optional)

Navigate to System Administrator Responsibility > System Profile Options
Assign a default operating unit to "MO: Default Operating Unit" profile option for
your responsibilities and/or user.
Assign MO: Operating Unit (Mandatory for only Single Org or if MO: Security Profile is not
defined)

Navigate to System Administrator Responsibility > System Profile Options
Assign the Operating unit to MO: Operating Unit profile option for your
responsibility or user.
Points to Note:
If both "MO: Security Profile" and "MO: Operating Unit" are defined then "MO: Operating
Unit" will be ignored and "MO: Security Profile" will be effective.
If we do not wish to implement MOAC features provided in Release 12, there are no
additional setups required. MO:Operating Unit is preserved through the upgrade, so if it
was set in the previous release, it will be set in 12.

Multi-Org User Preferences to Default Operating Unit
User can define preferences for defaulting the operating unit in transaction forms. This defaulting
can be achieved in two ways
Set the profile option "MO: Default Operating Unit"

This profile option will default into the Operating Unit field of MOAC enabled
transaction forms.

If the profile option "MO: Security Profile" is set and gives access to multiple Operating
Units, then the profile value "MO: Default Operating Unit", if set, is validated against the
list of operating units accessible. If it is included in the security profile then it is returned
as the default value. Otherwise there is no operating unit default and one must be selected
from the list of values. There is also no default provided when the profile option "MO:
Default Operating Unit" is not set.

If the profile option "MO: Security Profile" is set and gives access to only one operating
unit, this will be the default operating unit, even if "MO: Default Operating Unit" is set to
a different value.

If the profile option "MO: Security Profile" is not set, then the value of 'MO: Operating
Unit' is used as the default operating unit even if "MO: Default Operating Unit" is set to a
different value.
Define a default operating unit in the "Multi-Org Preferences" Page (Form Function
FNDMOPREFS)

If this function is included in your menu (generally included in seeded Payables Menus
for example), users can define "Default Operating Unit" in this page.

Effectively setting a value in this page will set the user-level value for the profile option
"MO: Default Operating Unit". This will override responsibility level settings.

Multi-Org User Preferences to Restrict Operating Units
Users can opt to restrict the list of operating units appearing in LOVs using the Multi-Org
Preferences Page (Form Function FNDMOPREFS). This is the same page mentioned above.
End-users can have preferred operating units which would represent a subset of operating units
assigned to their security profile.

For example, if a security profile assigned to a user or their responsibility has 10 operating units
assigned, but the user only deals with 5 of these on a daily basis this feature can be used to
restrict the list of operating units he sees to only those 5. Whe the user does not want to have to
view the extraneous operating units, he can set up Multi-Org preferences to restrict the list of
values.

MOAC and Concurrent Programs/Reports
While submitting a concurrent program that restricts data to a particular operating unit, we need
to select an operating unit for which to run the process. The "Submit Request" form will provide
a list of available operating units for our user and responsibility to choose from. This "Multi-Org
Reporting" allows you to report on data from one operating unit at time.

The Operating Unit field in the "Submit Request" form will be enable or not based on the value
of MULTI_ORG_CATEGORY in FND_CONCURREN_PROGRAMS for the concurrent
program. This field is not displayed in the "Define Concurrent Programs" window but it can be
viewed via Help > Diagnostics > Examine, if that function is available. If the value of this field
is 'S' (for single) the field will be enabled. If it is 'M' (for multiple) or null, it will not be enabled.

Please note that this type of "Multi-Org reporting" is not the same as cross-organization reports.
Cross-organization reports allow you to run a report at the ledger level to obtain results for all
operating units assigned to that ledger or to obtain results for all the operating units for a
GRE/Legal Entity.

Database technology used in MOAC
The MOAC feature primarily uses two database capablilities: namely, "Fine-Grained Access
Control" and "Application Context". Combined, these are known as "Virtual Private Database"
(VPD).

Fine-grained access control allows you to build applications that enforce security policies at a
low level of granularity (such rows/columns in table). Application Context provides a way to
define, set, and access attributes that an application can use to enforce access control specifically,
fine-grained access control .

See Note 462383.1 for a full explanation of these features and how they are used to implement
MOAC features.

MOAC uptake in Project Suite
The following are areas within the Projects application suite which are impacted by and/or utilize
MOAC functionality
Users can now enter data for multiple operating units from a single responsibility because the
operating unit field has been made available on forms that access the operating unit
striped data. For example, this field has been added to the following forms:

Pre-Approved Expenditure Entry
Expenditure Inquiry
Revenue and Invoice Review
WebADI templates
Capital Projects
Implementation Options
etc...

Once we assign access to multiple operating units to the responsibility, you can inquire
and adjust the data from a single responsibility by querying each operating unit
separately.
For concurrent processes and reports in Release 12, you can run the concurrent programs and
reports for multiple operating units from a single responsibility. This does not mean you
can run a single concurrent process across multiple operating units, but rather that you
can run the process for one of a selection of operating units that are available to you. To
see which concurrent programs allow you to select the operating unit, and which are not
operating unit dependent you can run the following query:

SELECT user_concurrent_program_name,
decode(multi_org_category, 'S', 'ENABLED', 'NOT-ENABLED') multi_org
FROM fnd_concurrent_programs_vl
WHERE application_id = 275
ORDER BY 2,1;
Project related APIs have added an org_id parameter which can be populated with the org_id
for the operating unit for which the API needs to be called.