5117723, 612 PM R12 MOAC Securty —KentW Limited KentW Limited = R12 — MOAC Security Multiple Organizations Access Control (MOAC) security give the possibility of querying or seeing transactions of one or more Operating Units (OU) without changing responsibility. In 11i we were securing transactions by Operating Unit (OU) only and we would have to choose a corresponding responsibility to see the transactions: * OUT - Receivables Manager * U2 - Receivables Manager © U3 - Receivables Manager In R12 it is now possible to have a shared services responsibility like: © ALL- Receivables Manager This new kind of security is based on Security Profiles which is a hierarchy of operating units. So best practice in R12 is now to secure all responsibilities by Security Profile rather than by Operating Unit. 11i non-MOAC setup: Site Level Receivables (Vision) MO: Default Operating MO: Operating Unit _| Vision Operations |Vision Operations MO: Security Profile GL Set of Books Name Vision Operations hitps hvu. kenta-comi2010/08t12-moae-securty 18sut73, 812 Pm R12 MORC Securty — Kent Limited Soa global shared service responsibility was not possible in 11i so some companies had very long lists of responsibilities Also note in R1i ite level setting takes precedence at lower levels so the responsibility level setting in this case is not needed — only if the OU had been different. R12 MOAC setup: Site Level Receivables (Vision) |Receivables (Global Mo: Default Oper: n Oper Vision Services Unit Mo: Operating Unit MO: Security Profile Vision Global {Vision Operations _| Vision Global Assuming we have a hierarchy like this where OU and security profiles have same names: > Vision Global >> Vision US >>> Vision Operations (OU) >>> Vision Services (OU) >> Vision Europe (OU) We do not need to have a security profile for all branches in the hierarchy above but it is best practice to do so. So in R12 GL Set of Books Name is gone and you leave MO: Operating Unit empty and leave it to the Security Profile. Note: MO: Default Operating Unit is not required and can be left empty however | have had several bugs in R12.1.1 and R12.1.2 related to missing default operating unit in IEX so try leaving it empty first and if you get problems put a default value in this and try again. So Oracle has created MOAC but forgot a few details here and there. Mixed R11i/R12 MOAC setup: hitps hvu. kenta-comi2010/08t12-moae-securty 2165117723, 612 PM R12 MOAC Securty —KentW Limited Some modules in R12 does not yet fully support MOAC so a mixed setup may be needed. Luckily Oracle changed the MO profile settings inheritance so the site level setting does NOT override at responsibility level as in R11i —well at least this setup worked in R12.1.1 Site Level Receivables (Vision) |Receivables (Global) Mo: Default Operating \Vision Operations Unit MO: Operating Unit Vision Operations Mo: Security Profile Vision Global_|Vision Operations _|Vision Global Using the setup above you will get a site level default OU of “Vision Operations” however at responsibility level the security profile takes precedence so Receivables (Global) will be able to see all OU's within “Vision Global’. In 11i you would have been locked down to “Vision Operations”. Technical 11i - View Based Security 11i used views to secure transactions in individual schemas: APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL With where clause using CLIENT_INFO set from the responsibility context. In PL/SQL programs you would set: © fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id); and: * dbms_application_info.set_client_info(var_organization_id); hitps hvu. kenta-comi2010/08t12-moae-securty 365117723, 612 PM R12 MOAC Securty —KentW Limited R12 — VPD Based Security R12 uses the Virtual Private Database (VPD) technology for MOAC security. ‘Synonym APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL With a policy attached to synonym APPS.AR_PAYMENT_SCHEDULES. In PL/SQL program you still need to set: * fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id); and for single OU access: * mo_global.set_policy_context('S',var_organization_id); or for multi OU access: * mo_globalset_policy_context(’M’null); Accessible Organisation Units In 11i it was easy to see what access you had: © dbms_application_info.read_client_info(var_organization_id); Which would return your current org_id however in R12 you need to do the following: * select organization_id from HR_ORGANIZATION_UNITS where MO_GLOBAL.CHECK_ACCESS(organization_id} Lusually use the following script: hitps hvu. kenta-comi2010/08t12-moae-securty 465117723, 612 PM R12 MOAC Securty —KentW Limited nto L_application tay ty ia select aser_ta __poliey_context ("Ht 1_oxgants Concurrent Requests Concurrent request can now be setup to run as in 111 (default) or as MOAC compliant programs, Use the “System Administrator” OAF screen “Concurrent Program" to set Operating Unit Mode to Single (OU) or Multi (MOAC compliant): hitps hvu. kenta-comi2010/08t12-moae-securty 565117123, 812 PM os totems | aetna nomen ig) Om etn Sates R12 MOAC Securty —KentW Limited Cet case Posted 04/08/2010 in Fun nal Knowledge, Security by Kent Willumsen Tags: MOAC, R12 KentW Limited nies kentw.con/2010/06/r12-moae-secury! Proudly powered by WordPress 816