CHAPTER
7

Security and Audit in Fusion Applications

The purpose of this chapter is to ensure that you can understand and work on the key security aspects in Oracle Fusion Applications across various features within this application suite. Every business application has a basic need to secure its resources and its data. Oracle Fusion Applications is no exception to those requirements. At a very high level there are two key components in any security model. These are authentication and authorization. Authentication means that the application ensures that a person accessing a protected resource has been validated for their username and password. The objective of authentication is to verify that the user is actually who they say they are. Once Fusion Applications identifies the user through authentication, then authorization is the basis for limits on what the user can do. For example, the authorization layer settings in Fusion General Ledger govern questions like these:

Is the user authorized to access the Journal Entry screen?

Should the user’s activity in the Journal Entry screen be restricted to a set of ledgers or balancing segment values in the Chart of Accounts?

Should the user be allowed to enter the journals and also to post the journals?

In this chapter, we will begin with giving an overview of the security model, followed by an explanation of how usernames, passwords, and their access are validated. The key emphasis, however, will be on authorization and data access in Authorization Policy Manager (APM). APM is the security layer that governs the screens, web services, and other components that the users can access and what data they can view or modify. We will see how the data security has been implemented in some of the key modules within Fusion Applications, taking examples in Oracle Fusion General Ledger in the context of ACME Bank.

Business Requirements

The ACME Corporation wants to ensure that accountants can access journals and balances related to the ledgers that they maintain. There is also a need to segregate the data visible by primary balancing segment values and lines of business. The line-of-business security will allow business owners to track the activities in their business streams. In order to implement these business requirements, it is important that we fully understand the security architecture of Oracle Fusion Applications.

Security Overview in Oracle Fusion Applications

Fusion Applications security is based on Role Based Access Control. The security layer in the product allows the system to assess who does what. The security layer ensures that you can only do what is appropriate for your job assignment.

The product comes out of the box with a predefined list of roles and permissions. This predefined configuration is also known as reference implementation, which provides over a hundred jobs. These jobs very closely match the actual jobs that people are hired to perform in enterprises.

Fusion Applications security is powered by Oracle Fusion Middleware; that is, the security capability is a part of the Fusion Middleware solution. Unlike Oracle EBS, Siebel, and PeopleSoft, the security layer is totally externalized from the modules and offerings. It also implies that in Fusion Applications, you configure your security rules in only one place across all the offerings, and they get referred to in various places in the business logic across all tools and technologies in the Fusion Applications stack. In other words, the product provides one way of securing access and data in a central place.

In a traditional ERP system, security administrators have to manage users and give appropriate access, and it is very common to have constant complaints about password management and integration between governance, risk, and compliance, making sure that we are compliant with all appropriate regulations that exist within an enterprise. Fusion Applications security not only reduces the risks but also the administrative costs that result in increased productivity. The security layer in Fusion Applications applies across all the tools in the product. For example, the security defined on General Ledger Balancing segment values will apply equally in user interfaces, Business Intelligence reports, analytics in Essbase cubes, and integrations.

Fusion Applications also introduces self-service provisioning and automated on-boarding so that the administrator doesn’t have to constantly work on user access, password provisioning, and so on. It allows staff to work on value-added activities such as defining the security policies for their enterprise.

The reference implementation provides transparency because the product externalizes security policies and puts them into an area where auditors can get a 360-degree view of access policies across the entire application. Fusion Applications also makes it easy to review and approve the access of individuals who are accessing the product.

Comparison of Security Model to Other Oracle ERP Products

In Fusion Applications, there is a job role such as General Accountant, which is probably equivalent to the top-level menu within E-Business Suite and also within Peoplesoft. The job role gives you the list of functions that should be available to an accountant in Oracle Fusion General Ledger. The next level down is the data role in Fusion Applications. A data role gives access to certain functions, but it also gives access to a set of data. So if you are a General Accountant for ACME UK Insurance, then you should be able to see the journals of ACME UK Insurance Ledger, but you should not be able to view the journals of ACME US Insurance Ledger.

Fusion Applications allows you to create a role hierarchy. This is just a grouping of privileges that you want to share between different jobs; for example, you might want to share a set of duties that are common to both General Accountant and an Intercompany Accountant, because both will need the ability to report on their chart of account balances.

The next level down is the duty role. The duty roles are mapped to the job roles. On a job board you will typically see a list of duties that will be performed by a job. For example, a General Accountant will manage journal entry, budget entry, and currency administration. In Oracle Fusion Applications, each of these activities are captured as duty roles. The reference implementation makes sure that each duty role can be verified as appropriate lines on a job description in various job portals.

The next level down is the level of privilege; for example, managing journals can involve various entitlements such as entering journals by spreadsheet or entering journals from screen or importing journals or deleting journals, and so on. In other words, deleting a journal is a task in the real world and corresponds to a privilege in Oracle Fusion Applications. These privileges are assigned to the duty roles. In the E-Business Suite, it is a Form Function, and in PeopleSoft, it is a Permission List.

The final level of security is the reference to the Permission levels in the source code of various toolsets in Oracle Fusion Applications. The development team locks access to executables that are the real pages or buttons and so on, or things such as Excel spreadsheets or web services within Fusion.

For readers with an Oracle E-Business background, Table 7-1 explains the analogy between the various security layers of Oracle E-Business and Fusion Applications.

TABLE 7-1. Fusion Applications and Oracle E-Business Security Layers

Figure 7-1 shows a diagram of the relationship between various components used in Oracle Fusion Applications security. The details for each component are explained in subsequent sections of this chapter. As you can see, the provisioning process begins with creation of the person in Fusion HCM (Human Capital Management).

FIGURE 7-1. Security objects in Fusion Applications

Architecture Components in Oracle Fusion Applications Security

Figure 7-2 shows the high-level components in Fusion Applications security. The actual technical stack has further Oracle components; however, the components listed in this figure will give you an idea of the architecture of Fusion Applications security. Even though some of these components may sound technical in nature, from our experience it is important that you understand these layers at a high level. During the implementation project, be it on-premise or cloud-based, you will be using most of these architectural components even when working in a Functional Configuration role.

FIGURE 7-2. High-level components in Fusion Applications security

Oracle Internet Directory

At the very back end of the security layers is an Oracle tool named OID (Oracle Internet Directory), where the user credentials are stored along with the user groups, permissions, and various other user login–related attributes. When you install Oracle Fusion Applications, a tool called ODSM (Oracle Directory Services Manager) gets installed as well, and it has a URL similar to http://hostname:port/odsm. ODSM allows you to interrogate the OID contents from a browser. Any kind of role that is created in Fusion Applications gets registered as a group within OID. The users that have access to that role get registered as the members of those groups in OID. Even though Fusion Applications provides user-friendly screens to create users, roles, permissions, and so on, behind the scenes, these get registered into OID’s LDAP-based repository. For SaaS customers, you will almost never get access to this repository, but on-premise customers will find this useful for troubleshooting.

Oracle Identity Manager

Oracle Fusion Applications also comes installed with OIM (Oracle Identity Manager). OIM allows a company to manage its users and their access to various roles centrally from a web console. Corporations implementing Fusion Applications on-premise have an option to leverage the Identity Management Suite installed as a part of Fusion Applications as an enterprise-wide system. This approach has some benefits such as out-of-the-box integration with Fusion Human Resources to manage leaver and joiner processes in order to allow automatic allocation and revocation of roles. Further possibilities include leveraging OIM’s integration with SOA (Service Oriented Architecture) within Fusion Middleware to facilitate various self-service–based user management approval processes and to streamline integration with the security card system of the corporation, integrating with canteen card facilities, staff gym membership, and so on, as applicable, subject to licensing costs verified with Oracle for the usage of the platform beyond Fusion Applications.

Authorization Policy Manager (APM)

Oracle Authorization Policy Manager is a web-based console for Oracle Entitlements Server (OES) with some additional capabilities for data security in Fusion Applications. As an implementer, this is the area where you will spend most of your hours in configuring security to match the business needs. APM is a fine-grained authorization product that defines policies that allow organizations to control security at a granular level. For example, coarse-grained security might allow or disallow a user from accessing a screen, whereas fine-grained security can allow or disallow users seeing specific buttons and might hide or show a field or make a field read-only and conditionally control data-related operations. At a very high level, APM has the components listed in the following sections.

Resource Types in APM

Every artifact such as a user interface screen or workflow process or Enterprise Scheduler Service or web service is associated with a resource type. APM allows you to define the possible actions that can be performed on each registered resource.

Resources in APM

Think of resource definition as registering a Fusion Applications artifact that is to be protected for access. For example, when defining a resource, you will capture the web service name or the path of the screen. A resource points to an actual physical deployed code that delivers a piece of functionality.

Entitlements in APM

After you register the resource in APM, next you define entitlements for that resource. These entitlements are also known as privileges in Fusion Applications. Here you can bundle a group of resources and specify the actions that are allowed on each such resource within the privilege. This bundling of resources along with the permissible actions allowed on them is called an entitlement. For example, a resource of type Journal Entry screen can have an action named Create Journals. When that entitlement is granted to a user via a role, then that user will be allowed to perform the specified actions on the resource as defined in the entitlement definition.

Duty Roles in APM

Using APM, you can create duty roles. Oracle Fusion Applications comes seeded with a long list of duty roles in the reference implementation. A duty role gives a representation of the features in the product that can be controlled for their access. For example, the Journal Entry role and Journal Posting role can be two separate duty roles. An organization may want a single individual to be disallowed from performing both the functions of entry and posting on the journal, even though both the actions can be performed from the same journal entry screen. To handle this scenario, the Oracle Fusion Applications product team would create one duty role for each of these activities. Duty roles are also referred to as application roles because these are specific to an application. For example, a duty role that allows creation of new employee records has to belong to the HCM (Human Capital Management) application and cannot belong to the Financials suite in Fusion Applications.

Authorization Policy in APM

Next you define an Authorization policy in APM. When defining the Authorization policy, you specify which duty roles can perform what actions on which set of resources. You do so by attaching one or more resources to a duty role within the Authorization policy definition. There are two ways to attach a resource to a duty role. You can either attach a resource directly to the duty role, or you can attach an entitlement to the duty role.

Oracle Platform Security Services

OPSS is the short name for Oracle Platform Security Services. You can think of OPSS as a decision engine that resides between the Oracle Fusion Applications code and the security repository. Each request made by the application is sent via OPSS to Oracle Identity Management; therefore, it is the central integration point between the application logic and the security layer. OPSS also has an auditing feature to log which user requested access to which resource and at what timestamp. This enables the Fusion Applications product to capture an audit of user interactions. As an implementer, you will never interact with the OPSS layer directly, unless you are a developer for an on-premise implementation.

Role Based Access Control (RBAC)

RBAC restricts access to the system based on the role of the user within the organization. Of course, the desired roles have to be granted to the user in the first place. RBAC in Fusion Applications defines “who can do what on which set of data.” In Fusion Applications the security based on RBAC has been implemented using a common framework across all its applications.

The terminology behind the various types of roles can be confusing. Therefore, for simplicity in this chapter, we will classify the roles into two types, that is, external roles and application roles. These roles can have further subclassifications as explained in Table 7-2.

TABLE 7-2. Types of Roles in Fusion Applications

Both application roles and job roles categorize the users into different groups. The job roles are categorized as per the company’s organization structure, whereas application roles are driven by the capabilities within the product. For example, if Fusion Applications were not to have a feature for Journal Posting, then there would be no point in defining an application role named “Journal Posting Duty.” Therefore, application roles also reflect the application features. Someone on the Oracle design team recognized the need that the Fusion Applications product must have a Journal Posting feature that can be potentially separated from the Journal Entry feature; therefore, they created these as two different duty roles.

Role Hierarchy

Both the external roles and the application roles support nesting via hierarchies. The hierarchical concept of roles is explained using Figure 7-3. As is evident from the example in this figure, the policies applied to the roles at a higher level are automatically inherited by the roles at a lower level. In other words, the policies added to the child roles are applied in addition to the policies for the parent roles.

FIGURE 7-3. Role hierarchy in Fusion Applications

Authentication in Fusion Applications

In order to appreciate the authentication approach implemented in Fusion Applications, it is important to highlight how the security works in traditional applications. In old-school enterprise software, the authentication process is local to the application itself, and in those systems, it is not possible to integrate authentication with a central corporate authentication system. Local authentication means that the user logins and their passwords are stored within the application tables itself instead of being stored in a centralized corporate repository. In the real world, staff can potentially be using dozens of applications across the enterprise. This has become even more widespread with cloud-based products being introduced into the enterprises.

Companies these days use a variety of systems in their enterprises. Some of these systems are hosted within the company data center, whereas other systems could be hosted in the cloud. In order to keep the user experience seamless, it is advantageous to have the same username/password across various applications. Fusion Applications makes centralized authentication a possibility because it delivers an out-of-the-box integration with Oracle Internet Directory and Oracle Identity Management.

Technically it is possible to use the on-premise Fusion Applications security platform for centralized corporate authentication, subject to your licensing agreement with Oracle. Alternatively, it is also possible to configure Fusion Applications to be authenticated from an existing centralized LDAP server such as Microsoft’s Active Directory, IBM’s Tivoli Directory Server, and so on. For example, every morning the staff walks into their workplace and logs in to their Windows terminal. Their username and password authentication occurs against an LDAP repository. Likewise, it is possible to configure Oracle Fusion Applications as well to authenticate against the same repository.

Typically, Human Capital Management (HCM) systems are the starting point for registering new staff into the organization. Therefore, you will find that the creation of employee records in HCM usually triggers the creation of new user records in Fusion Applications. In order to facilitate the use cases where users have to be automatically created from the HCM records, Oracle Identity Management has a feature that allows organizations to define their username construction logic. For example, some organizations will create a username called TSMITH for Mr. Tom Smith, whereas in other organizations they might want to automatically create a username of SMITHT. If the usernames are automatically generated, then the password, too, can be automatically generated by the system. Again, Oracle Identity Management allows implementers to write their own initial password creation logic.

Authorization in Fusion Applications

Permission to access a resource is called authorization. Authorization ensures that the user only has access to resources they have been specifically granted access to. These grants are also known as privileges or entitlements. These grants are defined in APM. APM is based on another Oracle Product named Oracle Entitlement Server (OES). In Fusion Applications, an authorization check is a combination of function and data security. It must be noted that the data security feature is not a part of Oracle Entitlement Server. The Fusion Applications team added the data security feature to OES under the umbrella of APM.

Function security ensures that a user can access only those resources for which they have been granted permissions. The data security controls access to the data. The authorization checks can either be enforced via APM or explicitly implemented by a developer either declaratively or programmatically.

Function security decides which user can perform which set of actions on which set of resources. A grant provides a role (or user) access for a permission set (or individual resource). The permission set is a grouping of related permissions required to complete a task. For example, the permissions to access a page and all related task flows may be grouped together into a permission set such that they can be granted together instead of granting each separately. This grouping of permissions is also known as entitlements.

Data Security

Data security defines “who can do what action on which set of data.” From this definition, “which set of data” can be enforced by appending a filter condition via a SQL WHERE clause.

APM User Interface

APM has a URL similar to https://host:port/apm. Figure 7-4 shows the key components of APM. As mentioned previously, the APM product is based on Oracle Entitlement Server. The Fusion Applications team, however, added a data security feature to OES. As shown in Figure 7-4, you can search for artifacts defined in APM by searching in the left-hand pane. When searching for components in the left-hand pane, it is important that you first select the application, because the policies defined in this area are application-specific policies segregated by HCM, FSCM, CRM, and so on. Application FSCM contains the Financials and Supply Chain Management artifacts. This includes component offerings such as Fusion Accounting Hub, Fusion Payables, Fusion Receivables, and so on. HCM is the Human Capital Management application, and CRM is the Customer Relationship Management application.

FIGURE 7-4. APM home page that allows you to secure artifacts in Fusion Applications

Exploring the APM Contents on the Public Website

Security reference implementation is the definition of authorization roles and policies that get delivered out of the box by Oracle Fusion Applications. Besides the APM, you can also browse the contents of reference implementation in https://fusionappsoer.oracle.com/oer/index.jsp. When you navigate to that URL, you will be asked to log in to your Oracle account first, and then you can select the guest option. Under Search Criteria Type, select Role. In the Logical Business Area field, select All Fusion Apps: Logical Business Area. Click the Search button and then select Fusion Accounting Hub or any other desired offering you want to explore. Under the Documentation tab, open Security Reference Manual.

How Does Oracle Secure Database Resources in Fusion Applications?

The data security policy is to secure the data in Fusion Applications. For example, if you are given access to the General Ledger Accounting Manager job role, you will still not be able to view or enter any journals or balances unless you have access to the ledger via the data security policy. In other words, with the job roles you may be able to see the screens but not operate on the data. The reason for this is that the function security is different than the data security. The data security is implemented in Fusion Applications by something called data roles, which are nothing but the wrappers around the job roles.

Oracle Fusion Applications delivers some out-of-the-box role templates that help in generating the data roles. The reason we have role templates is that the data roles always have a dependency on a job role.

In order to understand the data roles and templates, it is first important to understand how the security is implemented on the database resources. At the very end of the chain, it is a database table that contains the data that needs to be secured. If this database object needs to be secured, then it must be registered in APM by a Fusion Applications developer. Figure 7-5 shows the registration of the standard Oracle table GL_LEDGERS as an example.

FIGURE 7-5. Registered database resource in APM

In APM, as shown in Figure 7-5, to search on existing database objects that are secured, select Database Resources in the left-hand pane and then enter the name in the Search field and click the right arrow. Next, click the Edit icon to browse the database resource in APM. You will notice that it is mandatory to register the primary key of the database resource in APM. Functional consultants can always rely on Fusion Application developers in their team to implement these data roles. Implementers working on SaaS can seek help from Oracle Support with these data roles.

To create a set of WHERE clauses, a Fusion Applications developer can click the Condition tab as shown in Figure 7-6. Conditions are responsible for returning a set of rows at run time, and these conditions are known as instance sets. When the data roles are assigned to a user, then these conditions are applied at run time when the corresponding database resource is accessed via the applicable duty role in the application.

FIGURE 7-6. The conditions can be defined as SQL predicates.

Once the data is accessible, Fusion Applications then allows implementers to define the permissible actions. Actions can be insert, update, or delete. However, the product development team may define further actions on certain database resources. The Policy tab on the database resource is where job, action, and condition are stitched together for the data security, as shown in Figure 7-7. For example, in the Policy tab, you can define that the General Ledger Controller job has permission to update journals that belong to ACMECorp USA.

FIGURE 7-7. Policies that secure the data in Fusion Applications.

Role Templates

During the implementation project, when it comes to granting roles to the users, you will be granting job roles that are specific to certain data sets. For example, in Fusion General Ledger, you will have roles similar to General Accountant ACME_CORP_USA_Ledger. This role must be assigned to a General Accountant.

When building the product, the Oracle Fusion product development team made some basic data granularity decisions at design time. This data granularity has been achieved by something called a dimension. In Fusion Accounting Hub, one or more ledgers can belong to a GL access set. The product team decided to provide data security for GL-related job roles at the GL Access Set levels. Similarly, Fusion Payables provides security at the Business Unit level. In the case of Fusion Accounting Hub, the GL Access Set can be a dimension, whereas in Fusion Payables, the Business Unit can be a dimension. It must be noted that other security layers also exist that have been implemented in those products. During large implementations, there will be many possible values for the dimensions such as Ledgers or Business Units. It can become quite a laborious process for the implementation team to define job roles manually for each such dimension value. To ease this process, Oracle Fusion Application allows automatic generation of data roles that are wrappers around the job roles. This is achieved by means of a role template.

Figure 7-8 shows some of the role templates that exist out of the box in the product. APM allows you to define your own role templates as well, which is useful when you are developing custom modules and wish to leverage the security model framework delivered by Fusion Applications.

FIGURE 7-8. Role templates

These role templates come predefined with some components. These components can be extended, or new role templates can be created in APM by the project implementation team to secure the data in custom applications that you are developing.

At design time, each Fusion Application team decides the applicable dimensions for a set of job roles. For example, the Fusion Accounting Hub team decided that the accountant’s access to journals should be controlled by GL Access Sets, which in turn is based on GL Ledgers or primary balancing segment values.

Joiners, Movers, and Leavers

Oracle Fusion HCM provides a functionality that allows roles to be provisioned automatically to the users when certain conditions are met. This feature is available even for the Fusion Financials customers using the HCM in shared mode. This feature allows roles to be allocated to the users automatically based on certain attributes in their person definition. To implement this feature, you need to define a mapping between the role and a set of conditions. The conditions can be defined based on a person’s assignment attributes, such as department, job, system person type, and so on.

The role mapping can support the following:

Automatic provisioning of roles to users

Manual provisioning of roles to users

Role requests from users

Immediate provisioning of roles

A role is provisioned to a user automatically if the following conditions are true:

1. At least one of the user’s assignments satisfies all conditions associated with the role in the role mapping.

2. You select the Autoprovision option for the role in the role mapping as shown in Figure 7-9.

FIGURE 7-9. Automatically assigning the Expense Manager role to all Employee Managers

For example, you may want to automatically assign the Expense Management ACME US Corp role to employees who have the position of Manager in the ACME US Operations business unit. Automatic role provisioning occurs as soon as the user is confirmed to satisfy the role-mapping conditions, which can be when the user’s assignment is either created or updated. The provisioning process also removes automatically provisioned roles from users who no longer satisfy the role-mapping conditions. Therefore, in this example, if the person is no longer a manager, then the Expense Manager role will be automatically removed.

The automatic provisioning of roles to users may be rejected if it violates segregation-of-duties rules. Segregation of duties is a functionality that can help prevent fraudulent activities by preventing the provision of an invalid combination of roles to a user.

System Auditing

Auditing in Oracle Fusion Applications is in compliance with SOX, PCI, HIPAA, and other industry standards. This mitigates any security risk to an enterprise. This auditing framework is also applicable to custom extensions developed in Oracle Fusion Applications.

Using the audit feature, you can search what a specific user did on a specific date or over a date range. Or you can search by a business object to see who changed something on a set of tables. Within these business objects, the important attributes are preselected by the Oracle Product development team for auditing.

Even the direct update to databases via Web Services and batch update processes can be captured by the auditing feature in Fusion Applications. The key components audited in Oracle Fusion Applications are

System configuration changes

Security access changes

Business data changed by the user

During implementation you can decide the level of auditing that you wish to use. You may decide to cut down on the volume of data being captured during auditing. Some examples of auditing are

Who approved

Who made changes to security rules

Login attempts, both successful and failed logins

Who performed data migration

Customizations

Broadly speaking, there are two types of audits: audit of data changes and audit of events. Fusion Applications Business Objects capture audit of data changes using shadow tables. This approach is similar to Oracle EBS. However, the Fusion Middleware product also audits events such as authentication, successful login, and so on to a central audit table when those events have occurred. The reporting user interface can retrieve data from shadow tables and from common audit tables of Fusion Middleware.

The reporting of the audit history is shown in a single user interface for both data changes and events being audited.

Configuring System Audit Policies

Fusion Applications contains a user interface named Manage Policies. This is where you configure your audit policies. As shown in Figure 7-10, you can audit the business objects such as expense reports, value sets, and so on. For a user to be able to configure audit policies, they must have the Application Administrator job role.

FIGURE 7-10. Managing auditing policies in Fusion Applications

Within Oracle Platform Security Services, you can audit at a high or medium or low level. When you set this level to low, then only the critical events will be captured.

Figure 7-11 shows how you can enable the audit to track the changes to values in the value set values. This figure shows that Oracle Fusion Application presents to you a variety of predefined business objects on which auditing can be enabled. The product gives you further flexibility in auditing a selected set of attributes in the business objects. For example, Figure 7-11 shows how you can enable auditing for changes to value set values when either the Enabled flag or the End Date or the Start Date were to change.

FIGURE 7-11. Changing Audit value set values

Reporting on System Audit Policies

In order to see the audit data, you must have a job role named Internal Auditor allocated to the user. Figure 7-12 shows the Audit Reports user interface. To access this screen, click the Navigator menu and select the menu item Audit Reports.

FIGURE 7-12. Audit Search user interface

Using this search screen, auditors or administrators can see the changes made to the business objects and any audit captured in Fusion Middleware products used by Fusion Applications. For example, it is very common to audit which role was assigned to which user by whom and when.

In order to audit the business objects such as database tables, the implementers can easily build reports using BI Publisher straight from the browser to report data in shadow tables.

Implementing the Business Requirements

The business requirement is to create three users, with the access shown in Table 7-3. These examples assume that the user FAADMIN will already exist in the system and will have access to all the ledgers and balancing segment values via Data Access Sets for every ledger being assigned to this user. This user will also have access to OIM and APM via the IT Security Manager role. In order to create a system administrator user, visit the link http://goo.gl/8fwa9e.

TABLE 7-3. Business Requirements for ACME US Insurance Users

A data access set in Fusion General Ledger allows autocreation of data roles for access to Ledgers and Primary Balancing segment values. In the following exercises, we will see how the data access set controls the access to Ledger and Balancing segment values.

Create User ACMEUS01 and Related Roles

Log in as a FAADMIN user, and click Setup And Maintenance. In the left-hand pane click Manage Implementation Projects. Click on the project titled ACME Phase I Implementation Project. Expand the project task tree for Financials | Define Common Applications Configuration For Financials | Define Security For Financials | Define Data Security For Financials | Manage Data Access Sets. Click Go To Tasks. Here you will find that a data access set named ACME US Ledger already exists. This data access set is created by default for every single ledger automatically by the system, as shown in Figure 7-13.

FIGURE 7-13. The default access set created for every ledger

Next, click Search: Tasks and search for Role Template and click Search using the right-arrow icon. Click the Manage Role Templates task in the search window. Click Search Role Template and search using Display Name General%Ledger%. Click Open | Generate Roles. You will notice that Data roles with the following display names have been generated:

General Accounting Manager ACME US Ledger

Financial Analyst ACME US Ledger

Controller ACME US Ledger

Chief Financial Officer ACME US Ledger

General Accountant ACME US Ledger

Navigate to Oracle Identity Manager using a URL similar to http://host:port/oim. Click Administration in the top-right corner and click Create User. Create a user with the following details:

Last Name: ACMEUS01

User Login: ACMEUS01

Organization: Xellerate Users

User Type: Other

Password: Welcome1

Click Save and assign the roles as highlighted in Figure 7-14.

FIGURE 7-14. Assigning a data role for ACME US Ledger’s default data access set

Log in to Fusion Applications as user ACMEUS01 and reset your password as prompted. Click the Navigator icon as shown in Figure 7-15, and then click Journals under General Accounting.

FIGURE 7-15. Journal Entry screen

After logging in, create a Journal batch, followed by a Journal Header with the category Manual, and add a code combination to the journal lines. As shown in Figure 7-16, you will be able to select all the values in the Company and Line of Business segment. This is so because for this user, there is no data security defined for the Company segment, which is the Primary Balancing segment.

FIGURE 7-16. The default ledger access set does not restrict the list of values in the account segment.

Create User ACMEUS02 and Related Roles

In this example, we will create a user that will have access to just one value in the company segment. Log in as a FAADMIN user, and navigate to Manage Data Access Sets as was explained in the prior example. Click the + icon to create a new data set, with the following details:

Name: ACME US Mortgage Data Access

Chart of Accounts: ACME Global COA Instance

Accounting Calendar: ACME Monthly

Access Set Type: Primary Balancing Segment Value

In the Access Set Assignments region, click the plus sign (+).

Ledger: ACME US Ledger

All Values: Uncheck this check box.

Specific Values: Single Value

Segment Value: 12

Save the data access set as shown in Figure 7-17, and you will see a confirmation message that the corresponding data roles are being generated. Click OK.

FIGURE 7-17. The data access set created for a specific primary balancing segment value

Navigate to Oracle Identity Manager and create a user as shown:

Last Name: ACMEUS02

User Login: ACMEUS02

Organization: Xellerate Users

User Type: Other

Password: Welcome1

Click Save and assign the role as highlighted in Figure 7-18.

FIGURE 7-18. Assigning a data role for the Mortgage Company Segment value

Log in to Fusion Applications as user ACMEUS02, and reset your password as prompted. After logging in, create a Journal batch, followed by a Journal Header with the category Manual, and add a code combination to the journal lines. As shown in Figure 7-19, you will be able to select a value of 12 in the Company segment.

FIGURE 7-19. The data access set can restrict values in the Primary Balancing segment.

Create User ACMEUS03 and Their Roles

In this example, we will create a user that will have access to just one value in the company segment and one value in the Line of Business segment. The high-level steps for this exercise are listed in Table 7-4.

TABLE 7-4. Steps to Create Value Set Security

Create Abstract Role

Log in to Oracle Identity Manager, and click Administration; then click Create Role. Provide both the name and display name as XX_ACME_LOB_ABSTRACT as shown in Figure 7-20 and save.

FIGURE 7-20. Create an abstract role to allow data roles to be generated for value set values.

Create Role Template

The role template allows the data roles to be generated. In this case, we will create a role template for the Line of Business value set so that one data role can be generated for each Line of Business value.

Navigate to APM, and click Create Role Template. Provide the name XX_ACME_LOB_R_TEMPLATE and the display name as ACME Line Of Business Role Template. Click the External Roles tab, and attach the abstract role as shown in Figure 7-21.

FIGURE 7-21. Attach the abstract role to a role template.

Click the Dimension tab, and enter the SQL statement shown. In your implementations, you will give an appropriate name for your value set.

Click Preview, and you will be able to see all the Line of Business codes defined as shown in Figure 7-22.

FIGURE 7-22. Dimension for role template

Click the Naming tab, and provide a naming convention for the role templates to be generated. In this case, we will be concatenating ROLE_CODE with “-” followed by FLEX_VALUE. Click the Summary tab and click Generated Roles. You will be able to see all the generated data roles as shown in Figure 7-23.

FIGURE 7-23. Data roles generated for the abstract role

Secure the Value Set for Line of Business

Navigate to the task Manage Value Sets, and search for the ACME Line Of Business value set. Edit the value set definition, enable the check box for Security Enabled, enter XX_ACME_LOB_SECURITY as the Data Security Resource Name as shown in Figure 7-24, and click Save. You will find that the Edit Data Security button is now enabled.

FIGURE 7-24. Enabling value set security

Click the Edit Data Security button. We need to capture the filter condition to secure the value set value in the Edit Data Security window. Create a new condition for the database resource and add a condition for value 102, as shown in Figure 7-25. Check the Oracle support website for the list of operators that are eligible for the Oracle Fusion General Ledger module. If the Tree Operators check box is enabled, you can select descendants and siblings of any node in the value set hierarchy.

FIGURE 7-25. Value set filter for value set security

Click the Policy tab, and this is where you will associate the data role to the condition as shown in Figure 7-26.

FIGURE 7-26. Associate the generated data role to the filter condition.

Finally, you can navigate back to OIM and create user ACMEUS03 and assign roles to this user as shown in Figure 7-27. By doing so, for this user, the application will filter on the Line of Business 102 value.

FIGURE 7-27. Assign the data role for Line of Business 102 to the user.

Summary

In this chapter we have explained the architecture of security in Oracle Fusion Applications. We saw how the application layer integrates with the Oracle Identity Manager. The guided examples will help you implement the security for Oracle Fusion General Ledger. These examples have been written on Release 11.1.8 of Oracle Fusion Applications. Oracle Fusion Release 10 introduces a simplified reference model for Fusion Security, as detailed in Appendix A. Readers working on Fusion Release 10 or higher should refer to the appendix for the new features introduced in Fusion Applications security.