© Tushar Thakker 2015

Tushar Thakker, Pro Oracle Fusion Applications, 10.1007/978-1-4842-0983-7_13

13. Managing Fusion Applications Security

Tushar Thakker

(1)Param Labs, Dubai, United Arab Emirates

Fusion Applications Security is a vast subject and this chapter introduces some of the mandatory Security setup tasks in the initial implementation of Fusion Applications. As you learned earlier, Fusion Applications is based on Role Based Access Control (RBAC) and Segregation of Duties (SOD). This chapter helps you understand how Oracle achieves role-based access control at the same time applying segregation of duties policies in order to avoid unauthorized access to Fusion Applications transaction data or functional screens.

Components Involved in Common Security Setup

During the following discussions we will see a lot of different interfaces for specific activities. So let’s first understand the components involved in setting up and managing Fusion Applications Security. We have already seen these components earlier so we will only look at what role they play in the Users or Roles provisioning and management processes and how they relate to Fusion Applications Security.

Oracle Internet Directory

Oracle Internet Directory provides the LDAP identity store for Oracle Fusion Applications. Although Oracle Identity Management supports other LDAP directories as well, we discuss it here with reference to OID. Oracle currently supports only OID as a policy store so in this case both the identity and policy stores are hosted in OID. Regardless of the interface from where user or roles are being created, OID stores all these values in the identity and policy stores.

Oracle Directory Service Manager

Oracle Directory Service Manager (ODSM) provides a graphical interface to access Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD). We have already discussed ODSM during the IDM provisioning process. All references and screens in the following sections of this chapter related to OID identity and policy store browsing use ODSM as the interface.

Oracle Identity Manager

Oracle Identity Manager (OIM) manages the identity information and allows us to provision Users and Roles using a simple graphical interface. OIM maintains its own database for storing the identity information and it should be synchronized with LDAP for updated information of newly provisioned or deprovisioned Users or Roles.

Fusion Functional Setup Manager

As you saw earlier, the Fusion Functional Setup Manager provides a host of functionalities for implementation and administration purposes. We will be using the Manage Implementation Projects work area as well as running tasks manually using Fusion Functional setup manager. In order to access the work areas related to Functional setup manager, users must have the Functional Setups user role assigned either directly or indirectly via another role.

Authorization Policy Manager

While Oracle Identity Manager allows you to manage identity stores, Authorization Policy Manager (APM) allows you to manage policy store information. It allows you to create, configure, and manage application policies using a simple-to-use graphical interface. Once we look at the types of roles, you will understand that we can manage duty roles through APM while other Enterprise roles using OIM.

Table 13-1 shows summary of these components and the example URL to launch individual components along with the default login username. You will need to use these interfaces often in the following sections so you should keep these URLs handy.

Table 13-1. Important URLs for Fusion Applications Security Setup

Component

Example URL

Username

Oracle Directory Service Manager

(For Managing OID)

http://idmhost:7777/odsm

cn=orcladmin

Oracle Identity Manager

http://idmhost:7777/oim

xelsysadm

Fusion Functional Setup Manager

https://fahost:10634/homePage

FAADMIN (or equivalent)

Authorization Policy Manager

https://fahost:7777/apm

FAADMIN (or equivalent)

Fusion Applications Roles

By default, Oracle Fusion Applications users do not have access to any data or functionalities. Roles provide a mechanism to allow selective access to data and required applications functions. Unlike traditional applications suites, Fusion Applications provides granular control over resources based on functional and data security roles. This section looks at the types of roles available in Fusion Applications, including specific types of access control provided by each of these roles and how they relate to traditional applications suites including Oracle E-Business Suite.

Types of Fusion Applications Roles

Before we proceed with the Fusion Applications security setup, it is essential to understand how functional and data security on Fusion Applications Resources is provided using different types of roles. The following are main categories of roles we will discuss here. Duty Role, Job Role, and Abstract Roles provide basic functional security while Data Roles provide data security in addition to function security. Note that certain administrative job or abstract roles may allow restricted or unrestricted access to data as well. Let’s look at each of these roles and see how they are stored or accessed by various components of Fusion Applications.

Duty Role

Fusion Applications security provides the individual function or task level access control through Duty Roles. The lowest level function is called the Duty. We can compare Fusion Applications Duties with the Functions feature of Oracle E-Business Suite applications. An employee may have multiple duties as part of his/her job. Each of these duties are controlled as part of individual Duty roles. Duty roles are generally not assigned directly to users but instead are provided as part of other roles that we will discuss next. Duty roles are managed by the Authorization Policy Manager (APM), where you can see the mapping of other external roles with individual Duty roles.

Data roles are stored in the Oracle Internet Directory (OID) as follows. The given naming convention is not mandatory.

cn=<Name>_DUTY_<Application>,cn=Roles,cn=crm,cn=FusionDomain,cn=JPSContext,cn=FAPolicies

For example:

cn=AR_BILL_CREATION_DUTY_CRM,cn=Roles,cn=crm,cn=FusionDomain,cn=JPSContext,cn=FAPolicies

Job Role

We know that the definition of job in the real world is to perform a set of duties in an organization. Similarly Fusion Applications has predefined Job roles which inherit a set of Duty roles to combine the set of related duties to be performed as part of one’s job. We can compare this with the Responsibility feature of Oracle E-Business Suite Applications. For example, there is the Application Developer Job Role and General Accounting Manager Job Role. Job roles are also called Enterprise roles but in Authorization Policy Manager (APM) they are considered External roles. Job roles are managed and assigned through the Oracle Identity Manager (OIM). In OIM you can view the details of Job roles and other roles that they inherit or the other roles that inherit these roles. While in APM you can review the Job roles along with the set of duties allowed through the particular Job role.

Job roles are stored in Oracle Internet Directory (OID) as follows. The given naming convention is not mandatory.

cn=<NAME>_job,cn=fusiongroups,cn=groups,dc=<domain>,dc=<com>

For example:

cn=asm_application_implementation_manager_job,cn=fusiongroups,cn=groups,dc=paramlabs,dc=com

Abstract Role

We have seen that Job roles are created to combine a set of functional duties in an organization. Abstract roles are independent of specific functional duties but are generic roles that allow a user access to multiple functions which might not be related. For example, Employee role or Line Manager role. These roles are not tied to specific applications but they can perform a set of duties across multiple applications. Abstract roles are also managed through the Oracle Identity Manager in a similar way as Job roles. Abstract roles are also called Enterprise roles and, similar to Job roles, they are also referred to as External roles in Authorization Policy Manager in order to map them with specific duties across multiple applications.

Abstract roles are stored in Oracle Internet Directory (OID) as follows. The given naming convention is not mandatory.

cn=<NAME>_abstract,cn=fusiongroups,cn=groups,dc=<domain>,dc=<com>

For example:

cn=asm_application_implementation_admin_abstract,cn=fusiongroups,cn=groups,dc=paramlabs,dc=com

Data Roles

While Job and Abstract roles can be assigned to a user to provide functional access to the Fusion Applications interface, Data roles are required to provide access to the transaction data for the relevant application. By default, the access to all data is restricted unless explicitly provided through a specific Job role. We can consider a Data role as a set of SQL commands on top of a Job role to restrict data access to a specific set of transactions based on various dimensions. For example, you may want to restrict access to the General Ledger based on specific business units. So you may generate a set of Data roles on top of the existing General Accounting Manager Job roles which will be specific to each business unit and grant only specific Data roles to a user. Such Data roles can be generated from Data Role templates from Authorization Policy Manager. Additionally, custom Data roles can be generated as part of Setup tasks using HCM security profiles and stored in the OID identity store.

Data roles are stored in Oracle Internet Directory (OID) in one of the following namespaces and formats. The given naming convention is not mandatory.

cn=<Name>_DATA,cn=Groups,dc=paramlabs,dc=com (If created using HCM Security Profiles)

cn=<Name>_DATA, cn=FusionGroups, cn=Groups,dc=paramlabs,dc=com (If created using Generate Data Roles in APM)

For example:

cn=VIEW_ALL_FINANCIAL_APPLICATION_ADMINISTRATOR_DATA,cn=Groups,dc=paramlabs,dc=com

Figure 13-1 shows a graphical representation of how the roles are inherited from each other and provides a few examples of role assignment. However, these are only a few possible assignments and are only for understanding purposes.

A335101_1_En_13_Fig1_HTML.jpg
Figure 13-1. Examples of role assignment options

Accessing the Roles from Multiple Interfaces

To better understand the concept of Duty roles (Application roles) and Job roles or Abstract roles (Enterprise or external roles), let’s see how we can access and relate them to various interfaces. As you know, all the roles are stored in the Oracle Internet Directory under either identity store or policy store. While the Enterprise roles can be accessed and assigned from the Oracle Identity Manager, Duty roles may be managed from the Authorization Policy Manager.

Let’s take an example of a Job role—Application Implementation Consultant. This is the role that we will assign to the functional implementation user in the latter part of the chapter. Figure 13-2 provides an example walkthrough of how we can access the role in OIM, APM, and OID. In order to access the role in OIM, we can search for the role on the OIM Administration homepage. In the Details pane for this role, you can see the distinguished name for this role in LDAP. Using this DN, we can locate the same role in OID.

A335101_1_En_13_Fig2_HTML.jpg
Figure 13-2. Example of a role in OIM, OID, and APM

In order to look up the same role in Authorization Policy Manager (APM), you can search the same role using the External Roles Search function since Job and Abstract roles are treated as external roles in APM. Figure 13-2 shows how we can access them in APM and validate the role, which may match a role in OID as well under the cn=FusionGroups, cn=Groups, dc=paramlabs, dc=com namespaces.

After having seen these Job roles in OID, OIM and APM, let’s move on to Duty roles. As mentioned earlier, Duty roles are managed by the APM only so they are not available through the OIM interface. Duty roles are referred to as Application roles, so we can search for specific Duty roles using the Application Roles Search functionality. If you are not sure which Duty roles are part of a particular Job/External role then you can use the same External Role details screen and click on the Application Role Mapping tab, as shown in Figure 13-3.

A335101_1_En_13_Fig3_HTML.jpg
Figure 13-3. Example mapping of duties in APM and OID

Let’s take the same example role and look up the related Duty roles in APM as well as OID. Click on the Application Role Mapping tab as mentioned and you can go through the list of Duty/Application roles assigned to it. Let’s take example of a Duty role from the list, say Administration Link View Duty under the CRM application. We can look up the same Duty using the Application role search as shown in Figure 13-3 and locate the Duty role name in OID. Now we can navigate to the same Duty role in OID under the cn=FAPolicies, cn=JPSContext, cn=FusionDomain, cn=crm, and cn=Roles namespaces.

Looking Up Users and Roles in Database Tables

Although this is not required during most of the administration activities, at times you may want to troubleshoot the users/roles creation and assignment. If you want to generate user security reports from the database, knowing the relevant database tables for each components may become handy for Fusion Applications security administrators. Oracle does not recommend making any changes to any of these tables so you can use these or similar queries for reporting or understanding purposes only.

Let’s look at each of the components one by one and look up their users and assigned roles. In order to keep the output limited, I have created a user with the following details.

  • User Login: TUSHAR

  • Display name: Tushar Thakker

I have also assigned two roles to this user.

  • Application Implementation Consultant

  • Application Implementation Manager

Now let’s look up this user in the Fusion Applications HCM Database first. Figure 13-4 shows an example query to look up this user using the following tables.

  • FUSION.PER_USERS

  • FUSION.PER_USER_ROLES

  • FUSION.PER_ROLES_DN_TL

A335101_1_En_13_Fig4_HTML.jpg
Figure 13-4. Looking up users and corresponding roles in the Fusion HCM tables

Now let’s look up the same user and assigned roles in the OIM database. You may notice that the OIM query shows the default role of ALL_USERS as well, which is assigned to all users created in the OIM.

Figure 13-5 shows an example query to retrieve the User and Assigned role details from the following OIM schema (FA_OIM) tables:

  • FA_OIM.USR

  • FA_OIM.UGP

  • FA_OIM.USG

A335101_1_En_13_Fig5_HTML.jpg
Figure 13-5. Looking up users and corresponding roles in the OIM database tables

Finally, let’s see how to access User, Role, and Role Membership details in OID. The first two queries in Figure 13-6 can be used to look up User and Roles details individually from OID, while the last query shows how to look up the assigned roles and the namespaces in which the roles are located. These queries retrieve data from the following OID tables. There are many other tables also involved in each of these components.

  • ODS.CT_DN

  • ODS.CT_HRCH_QUERY

A335101_1_En_13_Fig6_HTML.jpg
Figure 13-6. Looking up users, roles, and hierarchies in the OID database tables

Setting Up Users and Roles Synchronization

Ideally all the previously discussed identity information, including the internal tables, should be in sync at any point in time, but whenever any provisioning activity is performed using external applications, HCM new hire process, or OID bulk load the identity information may remain out of sync for a brief period. In order to keep all these components in sync, Oracle has provided some built-in jobs that analyze OID/OIM/Fusion tables for any changes and apply those changes to the other components. Although most of these processes are scheduled automatically, you may need to run them on demand to synchronize the identity (between OID/Fusion HCM to OIM) and policy information (between Fusion HCM to OID).

Figure 13-7 provides a quick overview of which components are involved in each of these synchronization jobs and in which direction the synchronization is done between the components involved. We will explore these processes here and discuss how you can schedule or use them on demand.

A335101_1_En_13_Fig7_HTML.jpg
Figure 13-7. Identity synchronization process and relevant database tables

Oracle Identity Manager LDAP Reconciliation Jobs

Oracle Identity Manager includes predefined scheduled jobs for reconciliation of identity data between OIM and OID. You may need a user with either the SYSTEM ADMINISTRATORS or SCHEDULER ADMINISTRATOR role in order to access and run these reconciliation Jobs. Otherwise, we can log in with OIM Administrator user xelsysadm to perform these activities.

We can classify these LDAP reconciliation jobs into two major categories based on the way they synchronize the identity information between OIM and LDAP.

  • Full Reconciliation Jobs: The LDAP full reconciliation jobs perform a full synchronization of identity store entries between OIM and LDAP. These jobs should never be scheduled to run automatically but should be run on demand if the incremental reconciliation jobs are failing due to some missing entries or in the event that a bulk load has changed a large percentage of identity information. In such cases, full reconciliation jobs ensure that OIM and OID are in sync so that the future incremental jobs will run successfully. You should only run them when there is an absolute necessity or incremental jobs are failing. Full reconciliation jobs do not use the LDAP changelog entries so any errors related to unavailable changelogs will be fixed after these jobs are run. The following is the list of full reconciliation jobs available from the OIM scheduler.

    • LDAP Role Create and Update Full Reconciliation

    • LDAP Role Delete Full Reconciliation

    • LDAP Role Hierarchy Full Reconciliation

    • LDAP Role Membership Full Reconciliation

    • LDAP User Create and Update Full Reconciliation

    • LDAP User Delete Full Reconciliation

  • Incremental Reconciliation Jobs: As the name suggests, incremental reconciliation jobs apply changes from the last successful sync between OIM and OID related to the entries being synchronized. These jobs should be enabled and scheduled to run automatically (default is five minutes) in order to apply all changes transparently within the maximum five-minute window. If the incremental reconciliation jobs fail due to missing changelog information then you may run related full reconciliation job once and the incremental jobs would finish successfully. The following are the incremental reconciliation jobs available from the OIM scheduler.

    • LDAP Role Create and Update Reconciliation

    • LDAP Role Delete Reconciliation

    • LDAP Role Hierarchy Reconciliation

    • LDAP Role Membership Reconciliation

    • LDAP User Create and Update Reconciliation

    • LDAP User Delete Reconciliation

Let’s look at how to view all the LDAP-related OIM scheduled jobs and make sure that they have been set up with recommended settings. Log in to Oracle Identity Manager Service homepage using the OIM Administration user (xelsysadm). In the Self-Service homepage, click on the Advanced link in the top-right area, as shown in Figure 13-8, to launch the Identity Manager Advanced Administration console.

A335101_1_En_13_Fig8_HTML.jpg
Figure 13-8. Navigating to the OIM Advanced Administration

On the Advanced Administration page, you will see a list of dashboards. Click on the System Management tab and you will see a list of sub-tabs. Click on the Scheduler link to launch the Scheduled Jobs regional area, as shown in Figure 13-9.

A335101_1_En_13_Fig9_HTML.jpg
Figure 13-9. Search LDAP related scheduled jobs

In the Scheduled Jobs search box, type LDAP and run the search. You can also run an empty search to fetch all the scheduled jobs. Here we are going to focus specifically on job names starting with LDAP since those jobs are related to user and role synchronization with LDAP.

Caution

The name “scheduled jobs” may be misleading here since not all of these jobs are scheduled to run automatically or even enabled. Some of these jobs are scheduled by default while the remaining run on demand.

As I mentioned earlier, it is good practice to keep incremental LDAP reconciliation jobs scheduled to run at regular intervals to synchronize the data transparently without any manual intervention. Let’s see how to enable these jobs and select an automatic sync schedule. Click on any incremental job from the list, as seen in Figure 13-9. It will open the job details page as an additional tab in the main local region, as shown in Figure 13-10.

A335101_1_En_13_Fig10_HTML.jpg
Figure 13-10. Example of an incremental reconciliation job

There are three points to consider in order to enable this job to run automatically at regular intervals.

  • The Enable button should be grayed out, which means the job is already enabled.

  • The Schedule type should be set to Periodic.

  • Select Run every x minutes (set this value according to your environment and load) from the Job Periodic Settings area.

Apply the same settings for all the listed incremental reconciliation jobs. Also make sure that all the full reconciliation jobs are either not Enabled or No Predefined Schedule is selected under Schedule Type.

Manually Running OIM Reconcile Jobs

After the Fusion Applications installation is complete, it is a good practice to run the following full reconciliation jobs one time before you provision any additional users or roles for Fusion Applications. This is because sometimes the default seeded roles are not visible in OIM after the provisioning process.

  • LDAP Role Create and Update Full Reconciliation

  • LDAP Role Hierarchy Full Reconciliation

  • LDAP Role Membership Full Reconciliation

  • LDAP User Create and Update Full Reconciliation

Open these jobs one by one and click Run Now at the top to run them manually. The status of the job will change to Running for a brief period. Click the Refresh button to check the job status until the status changes to Stopped.

Fusion Applications LDAP Synchronization Tasks

Similar to OIM and LDAP synchronization, we may also need to periodically synchronize Identity information from Fusion HCM Users and Roles tables to LDAP via OIM. Once new users are provisioned through Fusion HCM, the user information is stored in PER_LDAP_USERS, PER_LDAP_ROLES, and a couple of other tables to enable pushing this data to the identity store. Oracle has provided two Scheduled Processes in order to synchronize between Fusion HCM and OID/OIM.

  • Send Pending LDAP Requests: This scheduled job pushes the incremental data from the Fusion HCM tables (including those with the prefix PER_LDAP_, which already contain the differential data) to the Oracle Identity Manager, which is in turn saved into the OID identity store. In most cases the data gets pushed to OIM transparently but we should make sure that this job runs frequently to make sure there is no pending update from Fusion Applications to Identity Management.

  • Retrieve Latest LDAP Changes: When a user or role is created outside Fusion HCM directly using OIM interface, we may need to bring those new identity data to Fusion HCM. This scheduled process may be run at least once daily in order to make sure that the identity information is in sync. During initial security setup of Fusion Applications, we may need to run this job after creation of implementation users using Oracle Identity Manager. We will look at that in upcoming sections. As you saw in Figure 13-7, this job pushes the data to the default identity tables in Fusion HCM—for example, PER_USERS, PER_USER_ROLES, PER_ROLES_DN, and so on.

Manually Running Fusion Applications LDAP Synchronization Tasks

You may schedule these Fusion Applications LDAP synchronization tasks to run at least once a day or more frequently. But at times you may need to run these tasks manually especially during the implementation phase when you create multiple users and roles directly in Identity Management. When you are running these jobs as part of the assigned implementation tasks, you get a link that points directly to the synchronization task execution page. You can also invoke these jobs in one of the following two ways.

  • Running the scheduled jobs directly using the Scheduled Processes work area

  • Invoking Users and Roles synchronization from the Tasks work area

Both of these yield the same result since the task also in turn redirects to the Scheduled Process. Let’s take a quick look at how to run these jobs and validate that they have completed successfully. First we will start with manual execution of the LDAP Scheduled Process. You can open the Scheduled Processes work area using Navigator ➤ Scheduled Processes. In the Overview screen, click on the Schedule new Process button, which launches the Search and Select pop-up window, as you can see in Figure 13-11.

A335101_1_En_13_Fig11_HTML.jpg
Figure 13-11. Search and run an LDAP sync scheduled process

In the pop-up screen, enter full or partial name of the Scheduled Process—for example Retrieve Latest LDAP Changes—and click Search. Select the appropriate job from search results and click OK to schedule the same. Alternatively you can invoke the same screen using the assigned implementation task or by searching for the task manually in the All Tasks work area, as shown in Figure 13-12.

A335101_1_En_13_Fig12_HTML.jpg
Figure 13-12. Search and run users and roles synchronization process task

Click on the Go to Task icon to launch the Scheduled Process specific screen, as shown in Figure 13-13. In fact, clicking on the OK button in the Search and Select screen will launch the same screen. Follow the same steps to schedule a new process as you learned in Chapter 11.

A335101_1_En_13_Fig13_HTML.jpg
Figure 13-13. Retrieving the latest LDAP changes

In this case, we are going to run the job immediately so you can just click the Submit button to run the job with the default parameters. However, as discussed in Chapter 11, you can select Advanced Options to select job output, notifications, and scheduling parameters. Make sure to run both Scheduled Processes discussed in order to synchronize in both directions. Once you are back to the main work area, search for both scheduled tasks and wait for the job to complete execution, as shown in Figure 13-14.

A335101_1_En_13_Fig14_HTML.jpg
Figure 13-14. Validate successful completion of the scheduled process

Make sure that the job completes with the status Succeeded to make sure that all pending LDAP changes are applied in both directions.

Fusion Applications Initial Security Setup

After going through the Fusion Applications Users and Roles Security concepts, it’s now time to set up the initial users and roles for the pilot implementation of the Fusion Applications modules. Regardless of which offerings are selected for the implementation project, the following User Administration tasks are mandatory and you may not need to do all these tasks in all future implementations.

Note

The Fusion Applications provisioning process already created the Fusion Applications super user (FAAdmin), which is capable of performing initial implementation of Fusion Applications modules. However, it is recommended that you dedicate separate users for Fusion Applications administration, security setup, and implementation.

Before we go ahead with the Security Setup tasks, let me give a quick overview of all the tasks that we are going to look at in this section. Figure 13-15 shows the step-by-step flow of Fusion Applications Security Setup tasks.

A335101_1_En_13_Fig15_HTML.jpg
Figure 13-15. Fusion Applications initial security setup tasks

You may notice a header block in each of the steps shown in Figure 13-15. I have mentioned the name of the component where the task needs to be performed along with the user who needs to be logged on to perform the selected task. All these mentioned tasks are related to the initial Security Setup of Fusion Applications and there will be additional advanced security-related tasks involved during and after the Applications implementation.

Update Fusion Applications Administration Super User

By default there is no valid e-mail ID assigned to the Fusion Applications super user FAAdmin created during the provisioning process. It is mandatory to have a valid e-mail ID assigned to the super user. Look up for the FAAdmin super user in Oracle Identity Manager and add a valid e-mail to the Email ID Identity Attribute. Figure 13-16 shows an example value for the FAAdmin e-mail address, which was changed from the default value of [email protected].

A335101_1_En_13_Fig16_HTML.jpg
Figure 13-16. Modify the e-mail attribute for the Fusion Applications super user

Setting Up the IT Security Administrator Role

The main role of IT Security Administrator user is to provision Fusion Applications Users and Roles using the Oracle Identity Manager (OIM) interface. Although in general the users will be created using the HCM interface, during the Implementation phase we need a dedicated user to provision users and roles outside the Fusion Applications interface.

Before we can create an IT Security Administrator user, we must prepare the IT Security Administrator role. By default the provisioning process creates this role with basic privileges to access the functional setup work area but not with identity Management-related privileges. Hence we must manually add Identity Management-related privileges to this user. Note that if there are any existing roles that already have required privileges then we should always assign that role as a parent role to other roles that require the same privileges. In this case we are going to add existing User Administrator and Role Administrator roles as parent roles to the IT Security Manager.

In order to achieve this, first we need to log in to the OIM homepage using the OIM Administrator user (the default value is xelsysadm). The URL for OIM is http(s)://<IDM Web Host or LB>:<Web Port>/oim.

For example:

http://idmhost.paramlabs.com:7777/oim

Once you log in to OIM using the xelsysadm user, you will see the Oracle Identity Manager Self-Service homepage, as shown in Figure 13-17.

A335101_1_En_13_Fig17_HTML.jpg
Figure 13-17. Oracle Identity Manager Self-Service homepage

You can see Advanced and Administration links on the top-right corner of the screen. Click on the Administration link to launch the Delegated Administration homepage. Now let’s look up and modify the existing IT Security Manager role in the OIM Administration console. As you can see in Figure 13-18, make sure that the Administration tab is selected. Under the Search category, select Roles from the drop-down menu and type the full or partial text of “IT Security Manager” in the Search box. Click the Search button. This will populate the list of users containing the search term. Since in this case we have entered full role name, we see only that specific role as the search result.

A335101_1_En_13_Fig18_HTML.jpg
Figure 13-18. Edit the IT Security Manager role

Click on the IT Security Manager role name from the search results. This will bring up details of the role in the main window as an additional tab. Click on the Hierarchy tab. You will see the existing parent roles assigned to this role. As you can see, by default this role has only one parent role, which is Functional Setup User. We need to add roles that are specifically required to manage users and roles in the Oracle Identity Manager. Click on the Add button to launch the Parent Roles selection pop-up frame, as shown in Figure 13-19.

A335101_1_En_13_Fig19_HTML.jpg
Figure 13-19. Add parent roles to the IT Security Manager role

As you can see in Figure 13-19, the roles are grouped by role categories (stored in the ROLE_CATEGORY database table in OIM schema). Since we are only interested in OIM-related roles at the moment, select OIM Roles from the drop-down menu. Select the following two roles from the left pane and move them to right using the arrow buttons.

  • IDENTITY USER ADMINISTRATORS

  • ROLE ADMINISTRATORS

The first role allows the user to create or modify users in Identity Manager while the later allows you to manage new or existing roles in Identity Manager. Note that these are bare minimum roles required for the IT Security Manager role during the Fusion Applications implementation and you may want to add more OIM related roles to this user, for example SCHEDULER ADMINISTRATORS, REQUEST ADMINISTRATOR, and so on.

Caution

Some external documents or blogs may suggest that you add the SYSTEM ADMINISTRATORS role to the IT Security Manager role. Note that although this role is a superset of IDENTITY USER ADMINISTRATORS and ROLE ADMINISTRATORS, it contains more privileges on Identity Management than required for the Fusion Applications implementation. Do not assign this role to the IT Security Manager unless you have a specific reason for doing so.

Figure 13-20 shows the post role-addition view of the IT Security Manager role. The first role, called Functional Setup Manager, is related to Fusion Applications. It allows the user to log in to Fusion Applications and access the Functional Setup Manager work area and access the tasks that are assigned to the user.

A335101_1_En_13_Fig20_HTML.jpg
Figure 13-20. Minimum required inherited roles for the IT Security Manager

Adding the IT Security Manager Role to the Xellerate Users Organization

At this point we have already assigned user and role administrator roles to the IT Security Manager role. However, we must first assign this user to the appropriate organization in Identity Management before it can manage the users in that organization. By default all users created for Fusion Applications should be created in the already existing Xellerate Users organization only. So we will add the IT Security Manager role as an administration role to this organization.

Note

The name Xellerate was inherited from Oracle’s acquisition of Thor Technologies in 2005. Thor’s Xellerate Identity Provisioning or Xellerate Identity Manager product is now transformed to today’s Oracle Identity Manager (OIM).

Let’s look at how to add this role as an administrative role to the Xellerate Users organization. In the OIM Delegated Administration console (which should be already open from the previous step), under the Administration tab in the regional area, select the search type as Organizations and perform an empty search. This will show you the list of existing organizations in your Identity Management environment, as shown in Figure 13-21.

A335101_1_En_13_Fig21_HTML.jpg
Figure 13-21. Accessing Xellerate Users Organization details

Click on the name Xellerate Users from the search results. This will launch the Xellerate Users details page as an additional tab in the main area of page. Click on Administrative Roles to launch the list of existing administrative roles, as shown in Figure 13-22.

A335101_1_En_13_Fig22_HTML.jpg
Figure 13-22. Default administrative roles for the Xellerate users organization

As you can see in Figure 13-22, by default only SYSTEM ADMINISTRATORS are allowed full administration access on this organization. ROLE OPERATORS have limited administration access on the same. We will add the IT Security Manager role with full administration rights in addition to these roles. Click on the Assign button at the bottom of screen to proceed. In the Search and Assign role screen shown in Figure 13-23, you can perform an empty search or filter with name of the role to be added.

A335101_1_En_13_Fig23_HTML.jpg
Figure 13-23. Search and add the new administrator role to the organization

Note that the role names being displayed in this screen are displayed in <parent_DN>.<ROLE_NAME> format. We performed the search with the same format to filter only the IT_SECURITY_MANAGER role.

For example, the full DN for the IT Security Manager is cn=FND_IT_SECURITY_MANAGER_JOB,cn=FusionGroups,cn=Groups,dc=paramlabs,dc=com and it is displayed as cn=FusionGroups,cn=Groups,dc=paramlabs,dc=com.FND_IT_SECURITY_MANAGER_JOB.

Once you have located the role to be added, select all three checkboxes for Write, Delete, and Assign permissions on this organization (Read is already checked and grayed out) and click the Assign button.

As you can see in Figure 13-24, it will prompt you with the list of roles selected for assignment. If you have performed an empty search and selected multiple roles across different pages then this screen becomes handy to get a summary of all roles to be added before the actual assignment. In this case, we are adding only one role so verify the name and click Confirm to assign the Administrative role.

A335101_1_En_13_Fig24_HTML.jpg
Figure 13-24. Administrative role assignment confirmation

Creating the IT Security Administrator User

Once you have set up the IT Security Manager role, you should create a new dedicated IT security manager/administrator user and assign this role to them. As mentioned earlier, the already provisioned super user FAAdmin has all the require permissions administer users/roles (via pre-assigned IT Security Manager role) and can manage the implementation project. But in order to segregate the duties and audit effectively, we must create a dedicated IT security manager user. It is also a good practice to create a new user for Fusion Applications Administration instead of using the FA super user (FAAdmin), since it has much more access privileges than day-to-day administration may require. You may also create a single user with administration as well as IT security role. This example shows you how to create the IT security manager/administrator user and assign required roles to them.

Open the OIM Administration homepage and click on Create User in the page main area or click on Create User in the search region. This will launch new user creation screen, as shown in Figure 13-25.

A335101_1_En_13_Fig25_HTML.jpg
Figure 13-25. Create new user screen

Table 13-2 describes the mandatory fields in this screen. Enter the values as shown in the Example column of this table and click the Save button to create the IT Security Administrator user.

Table 13-2. The Create New User Screen Parameters

Attribute

Input Type

Example

Last Name

<Valid String>

IT_Security_Admin

Organization

Xellerate Users (mandatory)

Xellerate Users

User Type

Non Worker (mandatory)

Non Worker

User Login

<Alphanumeric String>

IT_SECURITY_ADMIN

Login Password

<Valid String>

Str0ngP#$$w0rd

Display Name

<Valid String>

IT Security Administrator

Once the user is created you will be directed to the user details screen, as shown in Figure 13-26. Click on the Roles tab to access the list of currently assigned roles. By default, the newly created users have the ALL_USERS role only, so you must assign additional roles to this user in order to provide the required privileges.

A335101_1_En_13_Fig26_HTML.jpg
Figure 13-26. Post user creation screen

Click on the Assign button in the Roles tab to launch the Add Role screen, as shown in Figure 13-27. This screen requires you to enter the search criteria to filter the roles with matching names. You can search based on display name, role name, or namespace (parent DN of the role), either beginning with or exactly matching the value. However if you want to use the Containing search option, you can use wildcard “*” before and/or after the value.

A335101_1_En_13_Fig27_HTML.jpg
Figure 13-27. Search and add new role to an existing user

As shown in Figure 13-27, search for IT Security Manager role by entering and select the required row from the search results. Click Add to add the selected role to the user. The pop-up screen will close automatically. Figure 13-28 shows the list of direct and inherited roles now assigned to the IT Security Administrator user. Wait for a while to make sure that the LDAP incremental synchronization jobs have completed. You could use this user now to provision new Users and Roles in Fusion Applications. If you want a single user for administering the Fusion Applications environment as well as for provisioning users, then you can selectively add administrative roles that are already assigned to the FAAdmin super user to this user as well.

A335101_1_En_13_Fig28_HTML.jpg
Figure 13-28. Assigned roles for IT Security Administrator user

Assigning Users/Roles Provisioning Tasks to Security Administrator

Although this user can manually run users or roles provisioning related tasks, we must assign the related tasks from ongoing implementation projects to this user so that those tasks show up in the Assigned Implementation Tasks tab for this user. Let’s assign some tasks from an already created implementation project to the IT Security Administration assuming that this user is dedicated to security administration only.

Log in to Fusion Applications using the FAAdmin super user or the custom administration user (if one is created) and open the current implementation project. From the list of tasks, select the task or task list to be assigned and click on the Actions menu for the list of available actions for the task or list selected, as shown in Figure 13-29.

A335101_1_En_13_Fig29_HTML.jpg
Figure 13-29. Implementation Project Tasks actions menu

Click Assign Tasks to launch the assignment screen. By default, no user is assigned to a task until the task execution has been started. Click on the Add icon as shown in Figure 13-30 to search and add users to the task.

A335101_1_En_13_Fig30_HTML.jpg
Figure 13-30. Tasks assignment screen

The Search and Add users screen allows you to search an existing user using user ID, first or last name, or e-mail. Enter one of the criteria to look up the IT Security Administrator user, as shown in Figure 13-31, and click Search.

A335101_1_En_13_Fig31_HTML.jpg
Figure 13-31. Search and assign users to a task

Select the IT_SECURITY_ADMIN user from the search results and click Done. If you want to add more than one user using multiple search criteria then click Apply to let the screen remain open for another user assignment. Once the user has been assigned to the task, you can optionally add notes to the task, as shown in Figure 13-32, which can be viewed by the members of the implementation project team and can be used for documentation purposes.

A335101_1_En_13_Fig32_HTML.jpg
Figure 13-32. Adding notes to the task

Once the tasks have been assigned to the IT Security Administrator, this user can log in to the Fusion Applications homepage URL (for example, https://fahost:10634/homePage) and view the assigned tasks. Note that for every new user created in Identity Management, upon the first successful log in to Fusion Applications, the Identity Manager will request that the user to provide a new password and register security questions for future account recovery, as shown in Figure 13-33. It also shows the default password policy for selecting new passwords. Note that the default policy does not prevent the user from selecting the same password again. However, you can change the password policy as per your organization security requirements.

A335101_1_En_13_Fig33_HTML.jpg
Figure 13-33. Password Management screen upon first login

Once the you have logged in to Fusion Applications as the IT security administrator user, launch the Functional Setup manager page using Navigator ➤ Setup and Maintenance. The landing page will display the list of assigned implementation tasks for this user regardless of which implementation project they are assigned. The main implementation tasks for IT security manager/administrator are as follows.

  • Run User and Roles Synchronization Process

  • Create Implementation Users

  • Create Data Role for Implementation Users (optional)

  • Provision Roles to Implementation Users

Figure 13-34 shows the Assigned Implementation Tasks screen for the IT Security Administrator user.

A335101_1_En_13_Fig34_HTML.jpg
Figure 13-34. Assigned Implementation Tasks screen

You can click on Go Task one by one to complete these implementation tasks. Make sure to update the status of the task after it is completed successfully.

Run User and Roles Synchronization Process

The first step in an implementation project before creating any implementation users or assigning new roles is to synchronize Users and Roles information between the identity store and the Fusion Applications. The User and Roles Synchronization Process task is configured to run the LDAP synchronization Scheduled Process called Retrieve Latest LDAP Changes, which you saw earlier. Refer to the earlier section in this chapter for more details on this task.

Click on Go to Task for the Run User and Roles Synchronization Process task to launch the LDAP scheduled process screen and submit the request. Refresh the process status screen until the request status is Succeeded. Make a note of the request ID for documentation purposes. Since this task is now complete, click the Actions menu and select Edit Status to update the status of the task with optional notes, as shown in Figure 13-35.

A335101_1_En_13_Fig35_HTML.jpg
Figure 13-35. Updating the task status

Change the status from Not Started to Complete to make sure that the Implementation project is updated with the completed security tasks. You can add notes for documentation purposes, as shown in Figure 13-35. Click Save and Close to return to the list of assigned tasks. Note that the tasks that are set as Completed will not show up in the default view (All Open) unless you select the All Tasks option.

Creating Implementation Users

Once the Users and Roles Synchronization task is complete, you can go ahead with creating implementation user(s). Select the Create Implementation Users task in the list of assigned tasks for the current implementation project and click the Go to Task icon in front of this task. Since this task is related to Identity Management, it redirects you to OIM Self-Service homepage. Since you are already logged on as IT_SECURITY_ADMIN or an equivalent user, you need not log in again to OIM and you will be able to create or administer users and roles using Identity Manager. You must create at least one implementation user with the following roles if you want to provide unrestricted access to implementation users for the duration of initial setup.

  • Application Implementation Consultant

  • Application Implementation Manager

Since these roles have a wide range of functional and data security access on Fusion Applications Resources, you may want to restrict the access for the implementation users. In that case, we will not assign these roles but will create Data roles based on specific Applications administrator roles and assign them to the user. We will look at this in the next section.

Once you are redirected to OIM Self-Service homepage, click on the Administration link on top-right side and then click Create User in the main area to launch a new user creation screen, as shown in Figure 13-36. We have already seen this screen earlier when creating the IT Security Administration user so we need not explain the parameters again. You can refer to Table 13-2 for the list of mandatory parameters and acceptable values. In this case, we will name the user FA_IMPLEMENTOR with the display name of FA Implementor (different countries use the term implementor and implementer interchangeably), as shown in Figure 13-36. You may also set other optional parameters including Begin Date, End Date, and so on, for the user in order to disable such access after implementation is complete.

A335101_1_En_13_Fig36_HTML.jpg
Figure 13-36. Creating a new application implementation user

Create Data Roles for Implementation Users

The Application Implementation Consultant role has a wide range of access to Fusion Applications, including necessary access to all secure objects or resources. You may optionally want to restrict this access by creating Data roles that allow access only to a set of data based on the implementation requirement. As per the implementation requirement, we need to create View All and Set ID Data roles based on specific Applications Job roles. We can create Data roles using the following two methods.

  • Create a Data role using HCM security profiles in order to restrict or allow data access based on HCM conditions including Legislative Data Group, Persons, and Payrolls. This is the recommended method for creating a Data role for initial implementation users since they require View All permissions to set up the applications.

  • Generate Data roles using Data Role templates available in Authorization Policy Manager (APM), which secure data access based on multiple data dimensions and provide further granular control. This method is more suitable for granting access to regular Fusion Applications users instead of the initial implementation users.

The Generate Data Roles task is required to be performed at a later stage of the implementation project. For the initial application setup, the task by default leads to option 1 only. So let’s have a quick look at how to create a Data role for a specific application administrator Job role. Note that depending on the implementation tasks you may need to create one or more data roles that need to assigned to the implementation users in the next step.

Note

HCM domain WebLogic managed server hcmCoreSetupServer_1 is required to be available in order to generate data roles using HCM security profiles as well as to access the next functional implementation task of creating an enterprise structure.

Click on the Go to Task icon for the Create Data Roles for Implementation users task in the list of assigned implementation tasks. This will open the Manage Data Roles and Security Profiles page of the Fusion HCM core setup application, as shown in Figure 13-37.

A335101_1_En_13_Fig37_HTML.jpg
Figure 13-37. Manage Data Roles and Security Profiles page

In the Search Results section, click on the Create button to create a new Data role based on an existing Job role. This will lead to the Create Data Role page, as shown in Figure 13-38. This screen requires an existing Job role be selected. We created the View All Financial Application Administrator Data role based on the Financial Application Administrator Job role in this example.

A335101_1_En_13_Fig38_HTML.jpg
Figure 13-38. Create View All Data Role for financials application

The next screens allow you to select HCM security profiles based on the Persons, Payrolls, and Legislative Data groups. This role will be saved in the OID as follows.

cn=VIEW_ALL_FINANCIAL_APPLICATION_ADMINISTRATOR_DATA,cn=Groups,dc=paramlabs,dc=com

Assign Roles to Implementation Users

Once the user is created, it will now show the User details screen as shown in Figure 13-39. You can see that by default the user does not have any additional roles except ALL_USERS. Click on the Roles tab followed by the Assign button to add more roles to the FA administrator user.

A335101_1_En_13_Fig39_HTML.jpg
Figure 13-39. Implementation user details screen

We have seen the Add Role screen before. As shown in Figure 13-40, enter Application Implementation in the search box to display all roses that begin with this title. The following two Job roles should be displayed in the search results in addition to the Applications Implementation Administrator Abstract role.

  • Job roles

    • Application Implementation Consultant

    • Application Implementation Manager

  • Abstract role (optional)

    • Application Implementation Administrator

A335101_1_En_13_Fig40_HTML.jpg
Figure 13-40. Add roles to the implementation user

Or

  • Previously generated Data roles

    • View All Data roles

    • Set ID Data roles

Select both Job roles and then click the Add button to assign these roles to the implementation user. Figure 13-41 shows the final details of the FA implementation user with the required roles.

A335101_1_En_13_Fig41_HTML.jpg
Figure 13-41. List of assigned roles for the Fusion Applications implementation user

Rerun the LDAP Synchronization Scheduled Process

It is good practice to run the LDAP synchronization scheduled process after the required users and roles are provisioned. The synchronization may happen automatically but you can speed up the sync by manually running the scheduled process.

Summary

This chapter explored the initial security setup for Fusion Applications implementation. However this does not completely cover the Oracle Fusion Applications security tasks since many of them are beyond scope of this book. At this point you should understand the Role Based Access Control of Fusion Applications and how each component is involved in the Fusion Applications security architecture stores, and how it manages and synchronizes Users and Roles. You saw the various LDAP synchronization jobs between OIM and OID as well as between Fusion HCM and OIM.

Next you saw the mandatory security setup-related steps involved in Fusion Applications implementation project. At this point, your environment should have a security administrator user, an application implementation consultant user, and optionally a Fusion Applications administration user in addition to the initial FAAdmin super user. You got a bird’s eye view of how Data roles are created and assigned to existing users. The next tasks in the implementation project are performed by application implementation consultant and once the Fusion Applications environment is in operation, you or the Fusion Applications Administrator needs to monitor and maintain the environment. In next few chapters, you will learn about these important administrative tasks.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.97.75