| Oracle® Fusion Middleware Reference Guide for Oracle Business Intelligence Applications 11g Release 1 (11.1.1) Part Number E16816-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Reference Guide for Oracle Business Intelligence Applications 11g Release 1 (11.1.1) Part Number E16816-06 |
|
|
PDF · Mobi · ePub |
This chapter describes how to set up and maintain security for Oracle BI Applications.
This chapter contains the following topics:
Section 1.2, "About Security Configuration Tools in Oracle BI Applications"
Section 1.3, "Setting Up Security in Oracle BI Applications"
Section 1.6, "Implementing GL Segment Security in Oracle BI Applications for Fusion Adaptor"
Section 1.7, "Advanced Security Topics - About Data-Level Security"
Tip:
To set up security for new deployment of Oracle BI Applications, follow the steps in Section 1.1.1, "High Level Steps for Setting Up Security in Oracle BI Applications".
Oracle BI Applications 11g is tightly integrated with the Oracle Fusion Middleware Security architecture, and delegates core security functionality to components of that architecture.
Oracle BI Applications 11g is built on the Oracle BI EE platform, and security is configured using tools available to the Oracle BI EE platform.
For more information about the background and context of security for the Oracle BI EE platform, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
You should be thoroughly familiar with the security features of Oracle BI Enterprise Edition before you begin working with Oracle BI Applications.
This section contains the following topics:
Section 1.1.1, "High Level Steps for Setting Up Security in Oracle BI Applications"
Section 1.1.2, "What Tools Configure Security in Oracle Business Intelligence Applications?"
Section 1.1.3, "What Security Levels Does Oracle BI Applications Use?"
Section 1.1.4, "What Security Providers Does Oracle BI Applications Use?"
Section 1.1.5, "What Is a Security Policy and Where Is it Maintained?"
Section 1.1.8, "What Privileges Are Required to Run the ETL Process?"
Section 1.1.11, "About Permissions in DAC, Configuration Manager and Functional Setup Manager"
Section 1.1.12, "Additional Sources of Information About Oracle BI Applications Security"
To set up security in Oracle BI Applications, you must do the following:
Read the rest of Section 1.1, "Introduction" to get an overview of security concepts, tools, and terminology.
For background information about security in the Oracle Business Intelligence Enterprise Edition platform, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
Learn about Duty Roles, Job Roles, Data Roles, and Abstract Roles and how they control user privileges. For more information, see Section 1.1.6, "Controlling User Access Using Roles".
Note: Job Roles, Data Roles, and Abstract Roles are sometimes collectively referred to as Enterprise Roles.
The Oracle Fusion Applications provisioning process configures Users and default Fusion Applications Enterprise Roles in your LDAP directory.
For more information, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
If you need to manually map Users to Enterprise Roles, follow the steps in Section 1.3.1, "Creating Users and Assigning Them to Job Roles".
Fusion Applications Enterprise Roles in the LDAP directory are mapped by default to Duty Roles for Oracle BI Applications, which provides users with access to dashboards and data.
For background information about Oracle APM to manage Duty Roles, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges".
If you want to change the default role mappings, follow the steps in Section 1.3.2, "Assigning Enterprise Roles (or Job Roles) to Duty Roles".
Set up appropriate users for Oracle BI Applications components (for example, Oracle BI Applications Configuration Manager, and DAC).
This task is performed as step 'Grant User Access to Oracle BI Applications Components', in the post-installation steps for Oracle BI Applications. For more information, see the topic 'Grant User Access to Oracle BI Applications Components' in Chapter 4 of Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Applications.
When determining your user requirements, read Section 1.1.10, "Security Overview of Oracle BI Applications Configuration Manager and Functional Setup Manager".
The Oracle BI Repository is installed with default access permissions on installation. If the default access permissions do not meet your business requirements, then fine tune the access permissions for Roles by following the steps in Section 1.2.3, "Using Administration Tool to Configure Duty Role Permissions in the Oracle BI Repository".
The Oracle BI Presentation Catalog is installed with default privileges on installation. If the default privileges do not meet your business requirements, then fine tune the privileges granted for Roles by following the steps in Section 1.2.4, "Using the Oracle BI EE Administration Page to Configure Duty Role Privileges in the Oracle BI EE Presentation Server".
If required, configure Single Sign-On (SSO). For more information, see "Enabling SSO Authentication" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
If required, configure Secure Sockets Layer (SSL). For more information, see Section 1.4, "Configuring SSL for Oracle BI Applications".
For examples and typical setup scenarios, see Section 1.3, "Setting Up Security in Oracle BI Applications".
The figure below summarizes the tools used to configure security in a default installation of Oracle BI Applications using OID as the LDAP Server.
Use these Security configuration tools as follows:
Use Oracle Identity Management to manage Users and Job Roles (referred to as Groups in OID) in the LDAP directory. For more information about using OID tools, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
For detailed information about deploying OID, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
Oracle Authorization Policy Manager
Use Oracle Authorization Policy Manager (Oracle APM) to manage Duty Roles (also known as Application Roles), and permissions for determining functional access. For more information about using Oracle APM, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges".
For detailed information about Oracle APM, see Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Use the Oracle BI Administration Tool to perform tasks such as setting permissions for business models, tables, columns, and subject areas; specifying filters to limit data accessibility; and setting authentication options. For more information about using Oracle BI Administration Tool, see Section 1.2.3, "Using Administration Tool to Configure Duty Role Permissions in the Oracle BI Repository".
For detailed information, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
Oracle BI Presentation Services Administration
Use Oracle BI Presentation Services Administration to perform tasks such as setting permissions for Presentation Catalog objects, including dashboards and dashboard pages. For more information about using Oracle BI EE Administration Page, see Section 1.2.4, "Using the Oracle BI EE Administration Page to Configure Duty Role Privileges in the Oracle BI EE Presentation Server".
For detailed information, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
For detailed information about using these tools, see Section 1.2, "About Security Configuration Tools in Oracle BI Applications".
Security in Oracle BI Applications can be classified broadly into the following three levels:
User-level security (authentication of users). User-level security concerns the authentication and confirmation of the identity of a user based on the credentials provided, such as username and password. By default, user-level security is set up in the LDAP server and policy store. For more information, see Oracle Fusion Applications Security Guide.
Object-level security. Object-level security controls the visibility to business logical objects based on a user's role. You can set up object-level security for Oracle BI Repository objects, such as business models and subject areas, and for Web objects, such as dashboards and dashboard pages, which are defined in the Presentation Catalog. For more information, see Section 1.1.7, "About Object-Level Security."
Data-level security. Data-level security controls the visibility of data (content rendered in subject areas, dashboards, Oracle BI Answers, and so on) based on the user's association to data in the transactional system. For more information, see Section 1.7, "Advanced Security Topics - About Data-Level Security."
Oracle BI Applications uses the following security providers:
Credential store provider - the credential store enables access to the credentials required for authentication of users.
Identity store provider - the identity store contains information about user access to Oracle BI Applications, and is responsible for authenticating users.
For more information, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
Policy store provider - the policy store authorizes access of Oracle BI Applications Duty Roles, and determines what users can and cannot see and do in Oracle BI Applications. This forms a core part of the security policy, described in Section 1.1.5.
For more information about roles, see Section 1.1.6, "Controlling User Access Using Roles".
A security policy comprises a number of access privileges that are associated with user roles. In Oracle BI Applications release 11g, the security policy definition is split across the following components:
Presentation Services Catalog – Defines access to catalog objects and Oracle BI Presentation Services functionality using specific roles associated with users.
For more information, see Section 1.2.4, "Using the Oracle BI EE Administration Page to Configure Duty Role Privileges in the Oracle BI EE Presentation Server".
BI Repository – Defines access permissions in presentation area folders using specific roles associated with users.
For more information, see Section 1.2.3, "Using Administration Tool to Configure Duty Role Permissions in the Oracle BI Repository"
Policy Store – Defines access to Oracle BI Server, BI Publisher, and Real Time Decisions functionality using specific roles associated with users.
For more information, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
For more information about configuring these components, see Section 1.2, "About Security Configuration Tools in Oracle BI Applications".
This topic describes how Oracle BI Applications controls user access using roles, and contains the following sections:
After a user has been authenticated, the next critical aspect of security is to ensure that the user can do and see what they are authorized to do and see. Authorization for Oracle BI Applications release 11g is controlled by security policies (Oracle BI Applications privileges) defined for users using a role-based model (for more information, see Section 1.1.5, "What Is a Security Policy and Where Is it Maintained?").
Every Oracle Applications user is hired by their company to do a job in the organization. For example, Payroll Manager, AP Manager. Each job involves one or more duties. For example, a Software Development V.P. might hire people, carry out appraisals, make salary changes and stock grants to people in the group, manage project plans, approve expense reports, fill out vacation time, expense reports and update other personal details. Similarly an AP Manager might involve payable invoice approval, payable invoice processing, payables period closing, and some personal duties like filling out vacation time and submitting expenses. Thus job and duties form a hierarchy where a job has multiple duties and a person is hired to do a job. A job is represented by a Job Role. A duty is represented by Duty Role. A Job Role has access to one or more Duty Roles.
An Oracle Applications user is granted a Job Role and thus inherits one or more Duty Roles that were granted to the Job Role.
It is possible that a Job Role is built using other Job Roles, that is, Job Roles can form their own hierarchy. Similarly, Duty Roles can form a hierarchy.
It is possible to grant multiple Job Roles to a user; however Oracle recommends that Job Roles are defined in such a way that need to grant multiple Job Roles to user should be minimized.
Roles in Oracle BI Applications fall into two classes, application-wide roles (Duty Roles), and enterprise-wide roles (Job Roles, Data Roles, and Abstract Roles).
Application-wide roles are defined in terms of the tasks that are needed to perform a job, and are held in the policy store with associated Oracle BI Applications privileges.
Enterprise-wide roles are defined in terms of an occupation within an enterprise, and are held in the identity store with associated users.
Four common role types are used in Oracle BI Applications:
Job Roles (enterprise-wide roles, also referred to as Fusion Applications Enterprise Roles)
A Job Role represents the job definition of a person in your organization, for example, AP manager, HR specialist. Users are assigned to Job Roles. A Job Role inherits one or more Duty Roles, and therefore, users inherit Duty Roles through Job Roles.
For example, the Job Role AP_ACCOUNTS_PAYABLE_MANAGER_JOB might be associated with the Duty Role OBIA_ACCOUNTS_PAYABLE_MANAGERIAL_ANALYSIS_DUTY.
For more information about the Oracle BI Applications Job Role hierarchy, see Section 1.3.5, "Understanding Oracle BI Applications Job Role Hierarchies".
For more information about managing Job Roles, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles").
Duty Roles (application-wide roles, also referred to as Application Roles)
A Duty Role represents a specific task needed to do a job, and comprises the privileges required to perform that job. For example, the Duty Role BIA_ADMINISTRATOR_DUTY enables a user to administer and manage Oracle BI Applications, providing access to Oracle BI Applications Configuration Manager, and the Oracle BI Data Warehouse Administration Console.
The privileges assigned to a Duty Role are defined in application policies within the policy store. For more information, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges".
Data Roles (enterprise-wide roles)
A Data Role is implemented as Job Roles for a defined set of data. This role describes the job a user does within that defined set of data. The Data Role will inherit a Job Role and will be granted applicable data security privileges.
Data Roles grant specific data to users. For example, HR Admin UK has access to all UK employees, or Sales Rep West Coast can access West Coast customer accounts. Data Roles are built at the customer site as they are data dependant.
Data Roles are built using Job Role and permission grants on custom data. For example:
An Accounts Payables Specialist might be assigned the Data Role 'Accounts Payables Specialist - US Business Unit'. This Data Role inherits the Job Role 'Accounts Payable Specialist' and grants access to transactions in the US Business Unit.
A Benefits Administrator is assigned the Data Role 'Benefits Administrator - Surname A-E'. This Data Role inherits the Job Role 'Benefits Administrator' and grants access to Employees with the Surname starting from A to E. Typically, a person is hired into a job, which might trigger an event to automatically assign a Job Role without being assigned a defined set of data. A person in a functional department might at a later point in time assign his staff a Data Role that describes the job of that person within that defined set of data.
Data roles can be provisioned to a user on request. Data Roles can be formed by declaring child Duty, Abstract, and Job Roles.
For example, the Data Role OBIA_COSTING_ORGANIZATION_DATA_SECURITY might be associated with the Job Role OBIA_COST_ACCOUNTING_ANALYSIS_JOB.
Abstract Roles (enterprise-wide roles)
These roles are associated with a user irrespective of their job or job function, and are not associated with a job or duty. For example, Employee (Human Resources), Manager (Human Resources), Customer, Supplier etc. Abstract Roles are normally assigned by the system (based on user attributes) but can be provisioned to a user on request.
An example of an Abstract Role is ASM_APPLICATION_IMPLEMENTATION_ADMIN_ABSTRACT.
Figure 1-2 illustrates the relationship between Users, Job Roles, Duty Roles, and Oracle BI Applications privileges.
Figure 1-2 illustrates the following:
Users 1 and 2 have the Oracle BI Applications Job Role 'AP_ACCOUNTS_PAYABLE_MANAGER_JOB'. This Job Role is associated with the Duty Role 'OBIA_ACCOUNTS_PAYABLE_MANAGERIAL_ANALYSIS_DUTY' which enables associated users to analyze invoices and related documents along with payments, discounts, and payables balances.
User 3 has the Oracle BI Applications Job Role 'PER_PAYROLL_MANAGER_JOB', and User 4 has the Job Role 'PER_HUMAN_RESOURCES_JOB'. Both of these Job Roles are associated with the Duty Role 'OBIA_PAYROLL_ANALYSIS_DUTY' which enables these users to analyze payroll trends including earnings, deductions and taxes, and giving visibility to employee payroll details.
User 5 has the Oracle BI Applications Job Role 'GL_GENERAL_ACCOUNT_JOB', and User 6 has the Job Role 'GL_FINANCIAL_ANALYST_JOB'. Both of these Job Roles are associated with the Duty Role 'OBIA_GENERAL_LEDGER_AND_PROFITABILITY_MANAGERIAL_ANALYSIS_DUTY' which enables users to analyze GL account balance and profitability. It also enables drill from journal lines to subledger transaction details.
Object-level security is the specification of Duty Role permissions on Oracle BI Repository objects such as subject areas, tables, and columns, and Oracle BI Presentation Services objects, such as dashboard pages.
You secure these objects using Duty Roles and their associated policies and privileges, defined for Oracle BI Applications.
Duty Roles are stored in the Fusion Policy Store, which is accessed by the Oracle BI Repository and the Oracle BI Presentation Catalog.
For more information about default role mapping, see Section 1.5, "Mapping Roles to Secure Objects in the Oracle BI Repository and Oracle BI Presentation Catalog".
You implement object level security using:
Oracle Identity Management
To configure Users and Job Roles.
Oracle BI Administration Tool
To configure Oracle BI Repository Duty Role object permissions (for example, read, write against a subject area, table or column).
Administration page in the Oracle BI Presentation Catalog
To configure Oracle BI Presentation Services Duty Role object privileges (for example, access, view, or edit, a dashboard page).
For more information, see Section 1.2, "About Security Configuration Tools in Oracle BI Applications"
The Extract Transform and Load (ETL) process must be run by a user with appropriate data security privileges granted on the Fusion Application tables from which data is extracted into Oracle Business Analytics Warehouse. For this purpose, the Group named FUSION_APPS_OBIA_BIEE_APPID is provisioned during install with the appropriate ETL security privileges (by default, this Group is mapped to the Duty Role named OBIA_EXTRACT_TRANSFORM_LOAD_DUTY).
To create a user for ETL, use Oracle Identity Management (or an appropriate security tool) to create a new user and password. For example, you might create a new user named OBIA_ETL_USER. Then, make the user a member of the Group FUSION_APPS_OBIA_BIEE_APPID. For example, you might assign the user OBIA_ETL_USER to the Group FUSION_APPS_OBIA_BIEE_APPID. Finally, make a note of the user's credentials. This process is described in the post-installation setup steps in the topic 'Create a User for ETL' in Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Applications".
Note: The ETL user password is stored with the DAC connection details, and is not automatically synchronized with the LDAP version. Therefore, if you change the LDAP password of the ETL user is changed later, then you must also make the same changes to the DAC connection information. If the ETL user password expires, then you must reset it in LDAP, in the DAC connection details, and in Informatica > Relational Connections. To avoid this issue you can choose not to set an expiry date for the ETL user password (if your security best practices allow).
Oracle BI Applications content can be authenticated as follows:
Fusion Reporting Pane
User credentials are authenticated in the Reporting Pane login.
Oracle BI Applications dashboards accessed directly
The BI Presentation Server passes an authentication request to the BI Server, which uses the Identity Store.
Fusion Applications UI ("embedded Analytics")
In this scenario the user is already in Fusion Applications and therefore has already been authenticated.
To access Oracle BI Applications Configuration Manager or Functional Setup Manager (for Oracle BI Applications), a user must be granted one of the following Duty Roles:
BI Applications Administrator Duty (BIA_ADMINISTRATOR_DUTY)
Users with the BI Applications Administrator Duty Role have access to all Configuration Manager User Interfaces and all Functional Setup Manager User Interfaces. For Configuration Manager, only users with this Duty Role are able to perform system setup tasks.
BI Applications Implementation Manager Duty (BIA_IMPLEMENTATION_MANAGER_DUTY)
Users with the BI Applications Implementation Manager Duty Role have access to Configuration Manager Overview page and the Export and Import of Setup Data. In Functional Setup Manager, these users have access to Configure Offerings and Manage Implementation Projects User Interfaces but cannot execute a setup task.
BI Applications Functional Developer Duty (BIA_FUNCTIONAL_DEVELOPER_DUTY)
Users with the BI Applications Functional Developer Duty Role have access to Configuration Manager User Interfaces, except for the System Setup screens. In Functional Setup Manager, these users have access to the list of functional setup tasks assigned to them and have the ability to execute the setup tasks.
Assigning these Duty Roles to appropriate Users and Job Roles is performed as Step 8: 'Grant User Access to Oracle BI Applications Components', in the post-installation steps for Oracle BI Applications. For more information, see section 4.3.8 'Grant User Access to Oracle BI Applications Components' in Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Applications.
This section describes permissions in DAC, Configuration Manager and Functional Setup Manager, and contains the following sections.
Section 1.1.11.2, "About Permissions in Configuration Manager"
Section 1.1.11.3, "About Permissions in Functional Setup Manager"
For Oracle BI Applications, DAC permissions are granted through the Oracle BI Applications Duty Roles as follows:
BI Applications Administrator
- Read DAC Repository
- Administer DAC Repository
BI Applications Implementation Manager
- Read DAC Repository
- Manage DAC ETL
BI Applications Developer
- Read DAC Repository
- Design DAC Metadata
You login to DAC using the 'BI' connection type, because the DAC Server will run in Web mode. User authentication is handled by the LDAP directory where the DAC Server is deployed.
DAC permissions are as follows:
Read DAC Repository
resourceType=bi.dac.permission,resourceName=oracle.bi.dac.readDACRepository
Manage DAC ETL
resourceType=bi.dac.permission,resourceName=oracle.bi.dac.manageDACETL
Design DAC Metadata
resourceType=bi.dac.permission,resourceName=oracle.bi.dac.designDACMetadata
Administer DAC Repository
resourceType=bi.dac.permission,resourceName=oracle.bi.dac.administerDACRepository
Table 1-1 shows the list of Configuration Manager screens visible to each of the Oracle BI Applications Duty Roles.
Table 1-1 List of Configuration Manager Screens Visible to Each Oracle BI Applications Duty Role
| Oracle BI Applications Duty Role | Oracle BI Applications Configuration Manager screen | Associated Privilege |
|---|---|---|
|
BI Applications Administrator |
Overview |
BIA_OVERVIEW_PRIV |
|
BI Applications Administrator |
System Setups - Define Oracle BI Applications Instance |
BIA_DEFINE_INSTANCE_PRIV |
|
BI Applications Administrator |
System Setups - Manage Oracle BI Applications |
BIA_MANAGE_INSTANCE_PRIV |
|
BI Applications Administrator |
System Setups - Manage Preferred Currencies |
BIA_MANAGE_INSTANCE_PRIV |
|
BI Applications Administrator |
Functional Configurations - "Perform Functional Configurations" link to launch Functional Setup Manager |
BIA_FUNCTIONAL_SETUPS_PRIV |
|
BI Applications Administrator |
Setup Data Maintenance and Administration - Manage Domains and Mappings |
BIA_CONFIGURE_DOMAINS_PRIV |
|
BI Applications Administrator |
Setup Data Maintenance and Administration - Manage Data Load Parameters |
BIA_CONFIGURE_DATALOAD_PARAMS_PRIV |
|
BI Applications Administrator |
Setup Data Maintenance and Administration - Manage Reporting Parameters |
BIA_CONFIGURE_RPD_PARAMS_PRIV |
|
BI Applications Administrator |
Setup Data Export and Import - Export Setup Data |
BIA_EXPORT_SETUPS_PRIV |
|
BI Applications Administrator |
Setup Data Export and Import - Import Setup Data |
BIA_IMPORT_SETUPS_PRIV |
|
BI Applications Functional Developer |
Overview |
BIA_OVERVIEW_PRIV |
|
BI Applications Functional Developer |
Functional Configurations - "Perform Functional Configurations" link to launch Functional Setup Manager |
BIA_FUNCTIONAL_SETUPS_PRIV |
|
BI Applications Functional Developer |
Setup Data Maintenance and Administration - Manage Domains and Mappings |
BIA_CONFIGURE_DOMAINS_PRIV |
|
BI Applications Functional Developer |
Setup Data Maintenance and Administration - Manage Data Load Parameters |
BIA_CONFIGURE_DATALOAD_PARAMS_PRIV |
|
BI Applications Functional Developer |
Setup Data Maintenance and Administration - Manage Reporting Parameters |
BIA_CONFIGURE_RPD_PARAMS_PRIV |
|
BI Applications Functional Developer |
Setup Data Export and Import - Export Setup Data |
BIA_EXPORT_SETUPS_PRIV |
|
BI Applications Functional Developer |
Setup Data Export and Import - Import Setup Data |
BIA_IMPORT_SETUPS_PRIV |
|
BI Applications Implementation Manager |
Overview |
BIA_OVERVIEW_PRIV |
|
BI Applications Implementation Manager |
Setup Data Export and Import - Export Setup Data |
BIA_EXPORT_SETUPS_PRIV |
|
BI Applications Implementation Manager |
Setup Data Export and Import - Import Setup Data |
BIA_IMPORT_SETUPS_PRIV |
Functional Setup Manager Duty Roles are associated with Oracle BI Applications Duty Roles as follows:
The BI Applications Administrator Duty role (BIA_ADMINISTRATOR_DUTY) is associated to the following Functional Setup Manager Duty Roles:
ASM_FUNCTIONAL_SETUPS_DUTY
ASM_IMPLEMENTATION_MANAGER_DUTY
ASM_APPLICATION_DEPLOYER_DUTY
ASM_APPLICATION_REGISTRATION_DUTY
ASM_LOGICAL_ ENTITY_MODELING_DUTY
ASM_SETUP_OBJECTS_PROVIDER_DUTY
The BI Applications Implementation Manager Duty role (BIA_IMPLEMENTATION_MANAGER_DUTY) is associated to the following Functional Setup Manager duty:
ASM_IMPLEMENTATION_MANAGER_DUTY
The BI Applications Functional Developer Duty role (BIA_FUNCTIONAL_DEVELOPER_DUTY) is associated to the following Functional Setup Manager duty:
ASM_FUNCTIONAL_SETUPS_DUTY
When configuring security in Oracle BI Applications, in some circumstances you might need to refer to security in other areas, as follows:
Oracle Fusion Applications security
For more information, see:
Oracle Business Intelligence Enterprise Edition security implementation
For more information, see:
Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition
For information about Oracle BI EE platform integration with VOs, see the section 'Working with ADF Business Component Data Sources'.
To configure security in Oracle BI Applications, you typically use the following tools:
Oracle Identity Management - for more information, see Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
Oracle Authorization Policy Manager (APM) - for more information, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges".
Oracle BI EE Administration Tool - for more information, see Section 1.2.3, "Using Administration Tool to Configure Duty Role Permissions in the Oracle BI Repository".
Oracle BI EE Administration Page - for more information, see Section 1.2.4, "Using the Oracle BI EE Administration Page to Configure Duty Role Privileges in the Oracle BI EE Presentation Server".
Oracle Identity Management enables you to manage authenticated users, Job Roles, and Data Roles in the LDAP directory.
Note: If you use an alternative authentication provider (for example, Active Directory) you must use the console provided with the alternative authentication provider to create Users, Job Roles, and Data Roles. Oracle WebLogic Server Administration Console will also display this information.
For more information about managing Users and Groups (Job Roles, Abstract Roles, Data Roles), see:
Oracle Authorization Policy Manager (APM) enables you to create and manage Duty Roles that control access privileges to Oracle Business Intelligence resources (for Oracle BI Applications Configuration Manager, FSM, DAC, and dashboards and data in Oracle BI EE platform).
Job Roles (or Fusion Applications Enterprise Roles) in the LDAP directory are mapped by default to the pre-configured Duty Roles that are installed with Oracle BI Applications. For detailed steps on mapping Enterprise Roles to Duty Roles, see Section 1.3.2, "Assigning Enterprise Roles (or Job Roles) to Duty Roles".
Note: Fusion Middleware Control also enables you to manage Duty Roles for the BI Platform, but Oracle recommends using Oracle APM to create and manage Duty Roles.
For a detailed list of the default mapping between roles, see Section 1.5, "Mapping Roles to Secure Objects in the Oracle BI Repository and Oracle BI Presentation Catalog".
In Oracle APM, you can search on roles related to a specific functional area. To do so, navigate to the Search Role tab of the Role Catalog page, and select the appropriate functional area from the Category list.
For more information about configuring roles and privileges, see:
For background information about Duty Roles, see Section 4 'Role-Based Access Control' in Oracle Fusion Applications Security Guide
For additional information about using Oracle APM to create and manage Duty Roles (referred to as Application Roles in Oracle APM) see Chapter 5 'Managing Security Artifacts' in Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition)
Oracle BI Administration Tool enables you to configure Duty Role permissions (for example, Read or Write), for business models, tables, columns, and subject areas in the Oracle BI Repository.
For more information, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
Note: You use Fusion Middleware Control to manage the Oracle BI Repository (RPD) password (for more information, see Changing the Repository Password in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition)).
To configure Duty Role permissions on subject areas and tables in the Oracle BI Repository using the Oracle BI Administration Tool:
From the Windows Start menu, select All Programs, and Oracle Business Intelligence.
Log in to the Administration Tool.
Note: If you log in to the Administration Tool in online mode, then you can view all users from the LDAP directory. If you log in to Administration Tool in offline mode, then you can only view users that are stored in the repository.
To configure Duty Role permissions on subject areas and tables:
Choose Manage, then Identity to display the Identity Manager dialog.
The Application Roles tab displays, Application Roles, and Duty Roles.
Double-click a Duty Role to display the Application Role <Name> dialog
Click Permissions to display the User/Application Role Permissions dialog.
Display the Object Permissions tab.
Use the radio buttons (Read, Read Write, No Access) to set permissions for a Duty Role, on Oracle BI Repository objects.
Click OK to save your changes.
Close the Identity Manager dialogs.
To configure permissions for Duty Roles on a subject area or a table.
In the Presentation pane, double-click either a subject area icon (a cube), or expand a subject area, and double-click a presentation table to display the Permissions <Subject Area name>/<Table name> dialog for the chosen object.
Click Permissions to display the Permissions <Subject Area name>/<Table name> dialog.
Use the radio buttons (Read, Read/Write, No Access, and Default), to set permissions for Duty Roles on the selected Oracle BI Repository object.
Click OK to save your changes.
Close the Permissions dialogs.
Oracle BI EE Administration Page enables you to configure Oracle BI Presentation Catalog Duty Role privileges. For example, for dashboard and other content. For more information, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
You can use this page to grant specific privileges, for example to:
Manage Device Types
Access a subject area within BI Answers (for example, Subject Area: "General Ledger - Balances Real Time")
View a Dashboard Prompt
To configure Oracle BI Presentation Catalog Duty Role privileges:
Log in to Oracle Business Intelligence with Administrator privileges.
http://<hostname>:7001/analytics
Select the Administration link to display the Administration page.
Select the Manage Privileges link.
The following screenshot shows components, privileges and associated roles.
The following screenshot shows another view of the Manage Privileges page with subject area folders, privileges and associated roles.
Select a link to display the Privilege dialog, where you can grant or deny the privilege to the currently selected role.
Click the Add users/roles icon (+) to display the Add Application Roles, Catalog Groups, and Users dialog.
The following screenshot shows the available Duty Roles, which can be assigned to this privilege.
To configure permissions for Duty Roles on functional dashboards and reports:
In the top, click Catalog and expand Shared Folders in the left pane.
Click the required pillar or functional area folder to open it.
For example, select the Workforce Deployment dashboard under the Human Capital Management shared folder.
Click the More link for the Workforce Deployment dashboard to open the Permissions dialog box.
Use the Permission dialog box to add or modify role permissions for the Workforce Deployment dashboard.
Note: Similar steps can be taken to configure security for other objects in the Oracle BI Presentation Catalog.
This section describes how to set up security in Oracle BI Applications using the pre-configured Job Roles and Duty Roles that are installed. The setup process involves the following key tasks:
Users and default Enterprise Roles are set up by the Fusion Applications provisioning process.
If you want to change the default Users and Enterprise Roles in the LDAP directory, then follow the steps in Section 1.3.1, "Creating Users and Assigning Them to Job Roles".
Default Duty Roles are installed with Oracle BI Applications, and are mapped by default to appropriate Enterprise Roles.
If you want to change the default mappings for Duty Roles and Enterprise Roles in the Role Catalog, then follow the steps in Section 1.3.2, "Assigning Enterprise Roles (or Job Roles) to Duty Roles".
After you have installed Oracle BI Applications, you typically evaluate the product using the pre-configured users and roles. This section also describes how to create and develop your own modifications iteratively to meet your business requirements.
This topic contains the following sections:
Section 1.3.1, "Creating Users and Assigning Them to Job Roles"
Section 1.3.2, "Assigning Enterprise Roles (or Job Roles) to Duty Roles"
Section 1.3.4, "Granting Users Access to Oracle BI Applications Dashboards"
Section 1.3.5, "Understanding Oracle BI Applications Job Role Hierarchies"
Section 1.3.6, "Assigning Duty Role Permissions to Oracle BI Repository Subject Areas and Tables"
Section 1.3.7, "Assigning a Data Security Filter to a Duty Role"
Section 1.3.8, "Assigning Duty Role Privileges to Oracle BI Presentation Catalog Objects"
For information about configuring security for Oracle Business Intelligence, see the Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
When you create a new user you must assign them to one or more Job Roles or Data Roles using Oracle Identity Management. The new user inherits appropriate privileges from the Duty Roles that are associated with the Job Role or Data Role. New users are automatically added to the Fusion Applications Identity Store.
For more information, see Section 1.3.5, "Understanding Oracle BI Applications Job Role Hierarchies".
For Fusion Business Intelligence, Oracle Business Intelligence authenticates against Fusion Applications Identity Store at runtime.
To create a new user and assign the user to a Job Role or Data Role:
Use Oracle Identity Management as described in Section 1.2.1, "Using Oracle Identity Management to Manage Users and Enterprise Roles".
Create a new user using Oracle Identity Management (OIM).
For more information about creating users, and assigning to Job Roles and Data Roles), see "Role-Based Access Control" in Oracle Fusion Applications Security Guide.
Assign the new user to a Job Role or Data Role.
If the default Job Roles or Data Roles do not meet your business requirements, then create your own Job Roles or Data Roles.
For more information, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition)'
Note:
When you create a new User (or Job Role), at a minimum you must assign membership to two roles:
BIAuthor (an Oracle BI EE 'Application Role')
- for Oracle BI EE access privileges
OBIA_BUSINESS_INTELLIGENCE_APPLICATIONS_WORKER (an Oracle BI Applications 'Abstract Role')
- for Oracle BI Applications VO access privileges, if the user or role is Oracle BI Applications only
Oracle BI Applications is installed with a set of pre-configured Duty Roles that are mapped by default to appropriate Fusion Applications Enterprise Roles. For example, for Oracle HR Analytics, the Duty Role 'Workforce Deployment Analysis Duty' (OBIA_WORKFORCE_DEPLOYMENT_ANALYSIS_DUTY) is mapped to the Enterprise Role PER_LINE_MANAGER_ABSTRACT.
If the default security settings meet your business needs, then you do not need to alter the mappings. If the default security settings do not meet your needs, then you might:
edit the default Duty Roles and map them to different Enterprise Roles.
create new Duty Roles and map them to Enterprise Roles.
Follow the steps below to map an Enterprise Role to a Duty Role.
Prerequisite: Before you start, the Enterprise Role must already exist in the LDAP directory, and the Duty Role must already exist in the Role Catalog. You can either use one of the pre-configured Enterprise Roles that are installed with Oracle BI Applications, or you can use OID to create your own Enterprise Roles.
To map an Enterprise Role to a Duty Role:
In Oracle APM, navigate to the 'obi' Application and use the Search options to locate the Duty Role that you want to map.
Select the Duty Role, then click Open to display the <Application> | Application Role dialog.
Display the External Role Mapping tab.
Use the External Role Mapping tab to search for and select the Enterprise Roles that you want to map to that Duty Role.
Click Add to display the External Role Search dialog.
For example, the OBIA_WORKFORCE_DEPLOYMENT_ANALYSIS_DUTY Duty Role must be mapped to the PER_LINE_MANAGER_ABSTRACT Enterprise Role and the PER_HUMAN_RESOURCES_VP_JOB Enterprise Role.
Click Map Roles to map the Enterprise Roles selected to the Duty Role, and return to the External Role Mapping tab.
Oracle BI Applications is installed with a set of pre-configured Duty Roles. For example, for Oracle HR Analytics, the Duty Role 'Workforce Deployment Analysis Duty' (OBIA_WORKFORCE_DEPLOYMENT_ANALYSIS_DUTY) provides users with the required BI security privileges for that functional area.
If the default Duty Roles meet your business needs, then you do not need to change them. If the default Duty Roles do not meet your needs, then you might create new Duty Roles and map them to Job Roles.
Follow the steps below to create a Duty Role.
Log into Oracle APM, and select the 'obi' Application area.
In the Applications pane\Create area select the New Application Role link to display the <Application> | Application Role dialog.
In the General tab, use the Display Name field to specify the Duty Role name.
In the General tab, use the Role Name field to specify the Duty Role name in upper-case, with words separated with underscores, and prefixed with OBIA.
For example, for the Duty Role named 'Workforce Deployment Analysis Duty', specify 'OBIA_WORKFORCE_DEPLOYMENT_ANALYSIS_DUTY'.
Leave the Role Category field blank.
Click Save.
The other tabs only become active after you click Save.
At this point, you might want to map Job Roles to the new Duty Role now by following the steps in Section 1.3.2, "Assigning Enterprise Roles (or Job Roles) to Duty Roles", or you might want to map Job Roles to the new Duty Role at a later date.
Oracle BI Applications is installed with fully configured Enterprise Roles and Duty Roles that enable users to access BI dashboards. A user assigned to an Enterprise Role (also known as a Job Role) can access all BI dashboards and data that are appropriate to that role. The following examples illustrate how to provide access to BI dashboards using appropriate Enterprise Roles and Duty Roles.
The following examples describe granting a user access to a BI Applications dashboard:
Example 1: Granting a user access to an Oracle BI Applications AP dashboard without changing the default security settings.
In this scenario you would identify the appropriate Job Role assigned to the user, and check whether the appropriate Duty Role is assigned to that Job Role. If it is not, you assign the appropriate Duty Role to the Job Role to grant access to the Oracle BI Applications AP dashboard (for more information, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges").
Example 2: Granting a user access to an Accounts Payable (AP) dashboard by making changes to the installed security settings
In this scenario you would identify the appropriate Job Role assigned to the user, and check whether the appropriate Duty Role is assigned to that Job Role, if it is not, you would assign the appropriate Duty Role to the AP Manager Job Role to grant access to the Oracle BI Applications AP dashboard. For more information, see Section 1.2.2, "Using Oracle Authorization Policy Manager to Configure Roles and Privileges".
If suitable Oracle BI Repository permissions are not granted to a Duty Role, you can modify them for example, to enable or disable read/write permissions on a subject area or sub-folder. For more information, see:
If suitable Oracle BI Presentation Catalog privileges are not granted to a Duty Role, you can modify them for example, to enable or disable access to Dashboards, or view catalog objects. For more information, see:
Oracle BI Applications provides pre-built Job Role hierarchies for security to enable access to Oracle BI EE.
When you create a new role you must comply with the pre-built role hierarchies and naming convention that applies to Oracle BI Applications and OLTP roles:
Every Job Role must be assigned to two types of roles:
Oracle BI Applications BI Duty Roles - these provide:
access to one or more subject areas in the Oracle BI Repository and folders in Oracle BI Presentation Catalog
access to various Oracle BI EE platform permissions through inheritance of the BIAuthor role.
For example, to run reports and ad-hoc queries.
Oracle BI Applications BI Abstract Roles - these provide access to Oracle Business Intelligence View Objects (VOs)
For example, an Oracle BI Applications Job Role must be assigned to OBIA_BUSINESS_INTELLIGENCE_APPLICATIONS_WORKER Abstract Role for access to Oracle Business Intelligence View Objects.
Figure 1-6 illustrates the Oracle BI Applications pre-built role hierarchy and naming convention that applies to Job Roles and Abstract Roles.
Key to the Figure 1-6, "Oracle BI Applications Pre-Built Role Hierarchy Sample":
Job/Abstract Roles (for example, AP_ACCOUNTS_PAYABLE_MANAGER_JOB) inherit the following roles:
OLTP roles (not shown)
There will be many inherited OLTP roles.
Oracle BI Applications Content Duty Roles (OBIA_XXX_ANALYSIS_DUTY) - these allow access to one or more of the following:
Oracle BI Repository subject areas and tables
Oracle BI Presentation Catalog folders
For example, OBIA_ACCOUNTS_PAYABLE_MANAGERIAL_ANALYSIS_DUTY.
Oracle BI Applications Abstract Role - this enables access to the BI ADF Servlet
Note: There is only one Oracle BI Applications Abstract Role - OBIA_BUSINESS_INTELLIGENCE_APPLICATION_WORKER.
Oracle BI Applications Content Duty Roles (for example, OBIA_ACCOUNTS_PAYABLE_MANAGERIAL_ANALYSIS_DUTY) inherit the following roles:
BIAuthor Role - this allows access to Oracle BI EE features
Oracle BI Applications Data Security Duty Roles (OBIA_XXX_DATA_SECURITY) - these control data security in the Data Warehouse (DW)
For example, OBIA_PAYABLE_BUSINESS_UNIT_DATA_SECURITY.
Oracle BI Applications Currency Preference Duty Roles (OBIA_XXX_CURRENCY_PREFERENCES) - control reporting financial currency preferences
For example, OBIA_FINANCIAL_CURRENCY_PREFERENCES.
You grant Duty Role permissions to a Oracle BI Repository subject area or table to enable users associated with different Duty Roles to be granted different permissions in repository subject areas, and tables.
To assign Duty Role permissions to Oracle BI Repository subject areas and tables:
Edit the Oracle BI Repository, and set up permissions for a Duty Role as described in Section 1.2.3, "Using Administration Tool to Configure Duty Role Permissions in the Oracle BI Repository".
You assign a data security filter to a Duty Role to enable users associated with that Duty Role to view different data from a user associated with another Duty Role.
For more information, see Section 1.7.2, "Implementing Data-Level Security in the Oracle BI Repository"
You assign Duty Role privileges to Oracle BI Presentation Catalog objects to enable users associated with that Duty Role to be granted specific query permissions (for example, dashboard and other content).
To assign Duty Role Privileges to Oracle BI Presentation Catalog objects:
For more information, see Section 1.2.4, "Using the Oracle BI EE Administration Page to Configure Duty Role Privileges in the Oracle BI EE Presentation Server".
Secure Sockets Layer (SSL) for Oracle BI Applications enables secure communication between its components. Oracle BI Applications SSL is an extension of the Oracle BI EE platform SSL (SSL Everywhere), and must be manually configured after an Oracle BI Applications installation.
This topic references topics in other books that explain how to configure SSL for the Oracle BI EE platform and Oracle BI Applications, and contains the following sections:
You must configure SSL for the Oracle BI EE platform components before you can configure SSL for Oracle BI Applications components.
For information about configuring SSL for the Oracle BI EE platform components, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
If Oracle Content Server and the WebCenter application in which you intend to create a repository connection are not on the same system or the same trusted private network, then identity propagation is not secure. To ensure secure identity propagation you must also configure SSL on Oracle Content Server.
For more information, see Securing the WebCenter Spaces Connection to Oracle Content Server with SSL in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
You must also secure the connection between Oracle BI Applications Configuration Manager and Functional Setup Manager, as WebCenter portlet provider and consumer.
For more information, see Securing the WebCenter Spaces Connection to Portlet Producers with SSL in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
For information about default mappings for Duty Roles, Job Roles, and Data Roles, to secure objects in the Oracle BI Repository and Oracle BI Presentation Catalog, see Document 1333454.1 Oracle Business Intelligence Applications Duty Role Assignments for Fusion Applications on My Oracle Support:
This topic describes how to implement GL segment security in Oracle BI Applications with a Fusion Applications source system, and contains the following sections:
Oracle Financial Analytics supports a combination of the following security mechanisms for GL subject areas:
Security using GL Data Access Sets
Security using GL Accounting Segments
Data Access Set security is configured during installation and does not require additional configuration. This section gives an overview of the segment security, and describes how to configure security using GL Accounting Segments.
One or more value sets define the accounting segments in your OLTP. You can set up these value sets as a tree value set or non-tree value set. Users can have different types of access for each value set:
NOACCESS - User has access to none of the values in that value set.
FULLACCESS - User has access to all the values in that value set.
FILTEREDACCESS - User has access to specific values in that value set, defined as follows:
Tree valueset: If the valueset has a tree, then access to the user can be granted using "is-descendant of" hierarchical operator. This means that the user has access to that node and all the descendants of that node within that value set.
For example in the following illustration, if the user is granted "is-descendant of" node C, then the user has access to nodes C, D, E, F and G.
Non-tree valueset: If the valueset does not have a tree, then the user can be granted access to specific node/s or a range of nodes
Prior to configuring the segment security in the Oracle BI Repository, you should have completed configuring the segment dimensions in the Oracle BI Repository by mapping the segment VOs to the appropriate logical dimensions using BI Extender. Then perform the following tasks for each of the segment that you are securing. Based on the value sets used for those segments, the segment can be a tree enabled segment or a non-tree segment. The security implementation is different for these cases.
Perform the following steps when the segment on which security to be applied is a tree-based segment.
For tree-based value sets, the data security VO "FscmTopModelAM.DataSecurityAM.KFFHierFilter1" will give the different access types for the user as mentioned in the previous section. You will need to create a row wise session initialization block which reads from this VO. A sample SQL for this initialization block is as follows.
SET variable DISABLE_SQL_BYPASS=1, ApplicationIdBind='101', KeyFlexfieldCodeBind='GL#', SegmentLabelCodeBind='FA_COST_CTR': SELECT DISTINCT 'COST_CENTER_'||AccessType, CASE WHEN AccessType = 'FULLACCESS' THEN ValueSetCode ELSE ValueSetCode||'~'||TreeCode||'~'||TreeNodePk1Value END FROM "oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal"..."FscmTopModelAM.DataSecurityAM.KFFHierFilter1"
Turn ON the "Allow deferred execution" option for this initialization block.
Use the appropriate segment label code for the particular segment and any suitable prefix for the variable name, which are highlighted in bold text. In the above example, the segment label code used is "FA_COST_CTR" and the variable prefix used is "COST_CENTER_". This SQL will give (a) the value set codes the user has been granted full access to and/or (b) specific parent nodes within a tree the user has been granted access to using "is-descendant of" operator.
Create two session variables for the initialization block with names <prefix>_FULLACCESS and <prefix>_FILTEREDACCESS, where <prefix> is the variable prefix used in the initialization block SQL. For example, in the above case you will define two session variables with the name COST_CENTER_FULLACCESS and COST_CENTER_FILTEREDACCESS. Default them with a value '-1' (Varchar).
When the user has filtered access, we need to determine the hierarchy level in the hierarchy/tree where the node falls. For this you will need to create another row wise session initialization block. A sample SQL for this would be as follows. You will need to use the FILTEREDACCESS variable created in the previous step.
SELECT DISTINCT 'COST_CENTER_LEVELS', FIXED_HIER_LEVEL FROM "Oracle Data Warehouse"."Catalog"."dbo"."W_COST_CENTER_DH" WHERE LEVEL0_SECURITY_ID IN (VALUELISTOF(NQ_SESSION.COST_CENTER_FILTEREDACCESS)) AND CURRENT_FLG='Y'
Turn ON the "Allow deferred execution" option for this initialization block.
Please use "<prefix>_LEVELS" for the variable name in the select clause, where <prefix> is the same variable prefix used in steps 2 and 3. Please note the variable name used (in the where clause), should be the same as defined in the previous initialization block.
Create a session variable for the initialization block with the same name as used in the initialization block (COST_CENTER_LEVELS in this example) and default it with a value 0 (number). Set the execution precedence to make the initialization block mentioned in the previous step to run first.
You can refer to the initialization blocks "Cost Center Security" and "Cost Center Security Top Node Levels" in the repository installed by default, as a reference to create the above two initialization blocks.
Repeat the previous steps for each of the segment to be secured, giving a different name for the two initialization blocks and the three session variables for each segment.
Each segment dimension in the Oracle BI Repository (Dim - Cost Center, Dim - Balancing Segment, Dim - Natural Account Segment and Dim - GL Segment 1-10) can be either a tree or non-tree segment based on your requirements. In case you have configured them to be tree segments, perform the steps below after creating the initialization blocks and variables mentioned in Task 1.
Each dimension has 32 security columns, Level 0 Security Id through Level 31 Security Id, as shown below. The expression for each of these logical columns needs to be modified using the hierarchy level variable created above.
Open the logical table source of the dimension that maps to the warehouse dimension table and set the expression for each of these columns using the example from "Dim - Cost Center" dimension. For example, if you are securing by "Dim - GL Segment3" and the hierarchy level variable for this segment is "SEGMENT3_LEVELS", you would set the expression for each of the "Level <n> Security Id" column with the following:
INDEXCOL( IFNULL( VALUEOF(<n>, NQ_SESSION."SEGMENT3_LEVELS"), VALUEOF(0, NQ_SESSION."SEGMENT3_LEVELS")), "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_DH_Security_Segment3"."LEVEL31_SECURITY_ID", "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_DH_Security_Segment3"."LEVEL30_SECURITY_ID", "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_DH_Security_Segment3"."LEVEL29_SECURITY_ID", …and so on for each security id column… "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_DH_Security_Segment3"."LEVEL1_SECURITY_ID", "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_DH_Security_Segment3"."LEVEL0_SECURITY_ID")
Repeat the above steps for each of the segment dimension to be secured.
After completing Task 2, filters need to be added to the appropriate Data Role for data security predicates to be applied to queries. For more information, see Section 1.3.5, "Understanding Oracle BI Applications Job Role Hierarchies".
Navigate to "Manage -> Identity" from the menu.
Open the "OBIA_GENERAL_LEDGER_DATA_SECURITY" Duty Role.
Navigate to "Permissions -> Data Filters".
For each of the logical facts secured under this role, you will see some existing filters, which are handling data access security. You will need to append the segment security filters to this with an 'AND' condition. A snippet of the segment security filters to be appended for a given segment dimension is given below, assuming the security is on "Dim - GL Segment3" and the session variable prefix used in the previous steps was "SEGMENT3".
("Core"."Dim - GL Segment3"."Segment Value Set Code" IS NULL OR
((
"Core"."Dim - GL Segment3"."Segment Value Set Code" = VALUEOF(NQ_SESSION."SEGMENT3_FULLACCESS") OR
"Core"."Dim - GL Segment3"."Level 0 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR
"Core"."Dim - GL Segment3"."Level 1 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR
"Core"."Dim - GL Segment3"."Level 2 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR
...and so on for each security id column...
"Core"."Dim - GL Segment3"."Level 30 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR
"Core"."Dim - GL Segment3"."Level 31 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS")
)
AND
"Core"."Dim - GL Segment3"."Current Flag Security" = 'Y')
)
Repeat the above for each tree based segment dimension that is secured using appropriate variable names for each segment and appending each block of filters with an AND. For example, if you are securing by cost center and segment3 dimensions, the filter including the data access set security, will be as follows:
/* data access security filters */ ( "Core"."Dim - GL Data Access Set Security"."Ledger List" = VALUEOF(NQ_SESSION."LEDGER_LIST") OR "Core"."Dim - GL Data Access Set Security"."Ledger BSV List" = VALUEOF(NQ_SESSION."LEDGER_BSV_LIST") OR "Core"."Dim - GL Data Access Set Security"."Ledger MSV List" = VALUEOF(NQ_SESSION."LEDGER_MSV_LIST") ) /* cost center segment security filters */ AND ( "Core"."Dim - Cost Center"."Cost Center Value Set Code" IS NULL OR (( "Core"."Dim - Cost Center"."Cost Center Value Set Code" = VALUEOF(NQ_SESSION."COST_CENTER_FULLACCESS") OR "Core"."Dim - Cost Center"."Cost Center Level 0 Security Id" = VALUEOF(NQ_SESSION." COST_CENTER _FILTEREDACCESS") OR "Core"."Dim - Cost Center"."Cost Center Level 1 Security Id" = VALUEOF(NQ_SESSION." COST_CENTER _FILTEREDACCESS") OR "Core"."Dim - Cost Center"."Cost Center Level 2 Security Id" = VALUEOF(NQ_SESSION." COST_CENTER _FILTEREDACCESS") OR ...and so on for each security id column... "Core"."Dim - Cost Center"."Cost Center Level 30 Security Id" = VALUEOF(NQ_SESSION." COST_CENTER _FILTEREDACCESS") OR "Core"."Dim - Cost Center"."Cost Center Level 31 Security Id" = VALUEOF(NQ_SESSION." COST_CENTER _FILTEREDACCESS") ) AND "Core"."Dim - Cost Center"."Current Flag Security" = 'Y') ) /* segment3 security filters */ AND ( "Core"."Dim - GL Segment3"."Segment Value Set Code" IS NULL OR (( "Core"."Dim - GL Segment3"."Segment Value Set Code" = VALUEOF(NQ_SESSION."SEGMENT3_FULLACCESS") OR "Core"."Dim - GL Segment3"."Level 0 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR "Core"."Dim - GL Segment3"."Level 1 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR "Core"."Dim - GL Segment3"."Level 2 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR ...and so on for each security id column... "Core"."Dim - GL Segment3"."Level 30 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") OR "Core"."Dim - GL Segment3"."Level 31 Security Id" = VALUEOF(NQ_SESSION."SEGMENT3_FILTEREDACCESS") ) AND "Core"."Dim - GL Segment3"."Current Flag Security" = 'Y') )
Note: When a tree has more than one version, the security filters are always applied on the current version for that tree (CURRENT_FLG='Y'). However, you can navigate through any other version of the tree in the reports but security will always be applied on the current version.
Perform the following steps when the segment on which security to be applied is not a tree based segment.
Determine the name of the VO that was generated for the segment. It will follow a naming pattern such as FLEX_VS_<label>_VI, where <label> is the segment label defined in the OLTP.
Create a session row wise initialization block reading from this VO.
A sample SQL statement might be:
SELECT 'GL_MANAGEMENT_FILTEREDACCESS', ValueSetCode||'~'||Value FROM "oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal"..."FscmTopModelAM.AccountBIAM.FLEX_VS_GL_MANAGEMENT2_VI"
Use an appropriate prefix for the variable name, highlighted above. This initialization block gives a concatenation of value set code and values the user has access to.
Create appropriate session variable with the same name as used above and default it with a value '-1' (Varchar). In the above example, the variable name is "GL_MANAGEMENT_FILTEREDACCESS".
Repeat the above steps for each non-tree segment that needs to be secured.
After you have completed Task 1, filters need to be added to the appropriate Data Role for data security predicates to be applied to queries.
Navigate to "Manage -> Identity" from the menu, and open the "OBIA_GENERAL_LEDGER_DATA_SECURITY" Data Role.
Navigate to "Permissions -> Data Filters", and for each of the logical facts secured under this role, append the following filter to any existing filters with an 'AND' condition. The sample filter will look like:
( "Core"."Dim - GL Segment2"."Segment Value Set Code" IS NULL OR "Core"."Dim - GL Segment2"."Segment Code Id" = VALUEOF(NQ_SESSION."GL_MANAGEMENT_FILTEREDACCESS") )
Repeat the previous steps for each non-tree segment dimension that is secured using appropriate variable names for each segment and appending each block (one block per segment) with an "AND" condition. If you have a combination of non-tree and tree segments, then apply the data filters accordingly (as explained for each case) appending each filter with an 'AND' condition.
Data-level security defines what a user with a particular Duty Role in an OLTP application can access inside a report. The same report, when run by two different users (associated with different Duty Roles), can return different data. This is similar to how the My Opportunities view in an operational application displays different data for different users. However, the structure of the report is the same for all users, unless a user does not have access to a column in a report, in which case the column is not displayed for that user.
Data-level security works by granting a privilege conditionally to a user using initialization blocks that determine what data is available on log in (for example, the hierarchy level in the organization hierarchy, or responsibilities of a role).
BI session variables store information specifying the rows that a logged in user is permitted to see, and are used inside initialization blocks. Session variable initialization blocks are initialized using ADF BC View Objects (VOs).
This topic contains the following sections:
Section 1.7.2, "Implementing Data-Level Security in the Oracle BI Repository"
Section 1.7.4, "About Data-Level Security Design in Oracle BI Applications"
For more information about:
Oracle BI EE platform integration with View Objects (VOs)
See 'Working with ADF Business Component Data Sources' in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition)
Dimensions in the Oracle BI Repository, can be secured using the following methods:
In List
This method obtains a list of rows that the logged in user is allowed to see. For example, for organization-based security, this method might obtain a list of organization IDs. This list is obtained when the user logs into Oracle Business Intelligence, and is stored in an Oracle Business Intelligence session variable.
Top Node
This method is used for a hierarchical dimension, and obtains the top node to which the user has access, and stores it in the session variable. When querying the warehouse facts, the cached top node can be used along with flattened hierarchy tables within the warehouse to apply security on Oracle BI Applications tables.
Resource or Resource Hierarchy
This method requires ETL to the data warehouse of all data in Sales Resource dimension, Sales Resource Hierarchy dimension, and (Fact - Sale Resource/Sales Resource Hierarchy) helper tables. When querying a fact table, the login user's Party ID (session variable USER_PARTY_ID, initialized by querying UserPVO) determines what rows in the Resource dimension, and/or Resource Hierarchy dimension, and/or the helper table that the user can access, which then determines what data the user can access in the fact table.
Note: Installed dimension security configuration for "In List" and "Top Node" is obtained from Fusion OLTP at runtime. If the dimension security gets into the data warehouse through ETL, then it is obtained from OLTP during ETL time, not runtime.
Data-level security in Oracle BI Applications is implemented in three major steps, as described below. For detailed information about this security feature, see 'Applying Data Access Security to Repository Objects' Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
To implement data-level security in the Oracle BI Repository:
Set up initialization blocks that obtain specific security-related information when a user logs in, for example related to the user's responsibilities.
Set up the joins to the appropriate security tables in the metadata physical and logical layers.
For detailed information about this security feature, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
Set up the filters for each Duty Role on each logical table that needs to be secured.
For detailed information about this security feature, see 'Setting Up Row-Level Security' in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
Some initialization blocks for obtaining a given user's primary position, primary organization, and the owner ID, are preconfigured in the Oracle BI Repository. For more information, see the Oracle Business Intelligence Administration Tool.
For more information about setting up and managing initialization blocks, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
As discussed in the preceding sections, Oracle BI Applications maintains data-level security Duty Roles that are assigned dynamically to every user at the session level. Each Duty Role has a set of filters associated with it that determines the data each user is allowed to see. A user is assigned a Duty Role through the Authorization initialization block, as discussed in Section 1.7.3, "About Pre-Configured Initialization Blocks Used for Data-Level Security in Oracle BI Applications."
The data security design has the following features:
Drill down. The user can drill down on a particular position in the position hierarchy to slice the data by the next position level in the hierarchy. For example, if the initial report is defined as:
select Top Level Position, Revenue from RevenueStar
then by drilling down on a value of MyPosition in the TopLevelPosition hierarchy, the report will become:
Select Level8 Position, Revenue, where TopLevelPosition = 'MyPosition'
Personalized reports. Users at different levels of the Position hierarchy can use the same Position-based reports but with each user seeing the data corresponding to his or her level. In such reports, Position is a dynamic column.
For example, if a report is defined as:
select Position, Revenue from RevenueStar
the logical query for the user at the top level of the hierarchy will be:
select Top Level Position, Revenue from RevenueStar
The logical query for the user at the next level of the hierarchy will be:
select Level8 Position, Revenue from RevenueStar
CURRENT Position hierarchy columns. Position hierarchy columns with the prefix CURRENT contain the Current Position hierarchy at any point of time. This feature allows users to see the same data associated with the employee holding the Current Employee position at the time the report runs. This type of Analysis is called As Is.
Additional Position hierarchy columns. The columns EMP_LOGIN and EMPLOYEE_FULL_NAME are used at every level of the Position hierarchy to store additional information about an employee holding a particular position. In the Logical layer, the Employee path and Position path are two drill down paths under the Position hierarchy that allow the user to drill down on a position to see all positions under it. It also allows an employee to see all the employees reporting to him or her.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|