MOAC Setup Detials

 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.