D Managing Security for Dashboards and Analyses
This appendix explains how to manage security for dashboards and analyses such that users have only:
-
Access to objects in the Oracle BI Presentation Catalog that are appropriate to them.
-
Access to features and tasks that are appropriate to them.
-
Access to saved customizations that are appropriate to them.
This appendix contains the following sections:
-
Managing Security for Users of Oracle BI Presentation Services
-
Determining a User's Privileges and Permissions in Oracle BI Presentation Services
-
Controlling Access to Saved Customization Options in Dashboards
D.1 Managing Security for Users of Oracle BI Presentation Services
System administrators must configure a business intelligence system to ensure that all functionality (including administrative functionality) is secured so that only authorized users can access the system to perform appropriate operations. Administrators also must be able to configure the system to secure all middle-tier communications.
This overview section contains the following topics:
-
Section D.1.1, "Where Are Oracle BI Presentation Services Security Settings Made?"
-
Section D.1.2, "What Are the Security Goals in Oracle BI Presentation Services?"
-
Section D.1.3, "How Are Permissions and Privileges Assigned to Users?"
D.1.1 Where Are Oracle BI Presentation Services Security Settings Made?
Security settings that affect users of Presentation Services are made in the following Oracle Business Intelligence components:
-
Oracle BI Administration Tool — Enables you to perform the following tasks:
-
Set permissions for business models, tables, columns, and subject areas.
-
Specify database access for each user.
-
Specify filters to limit the data accessible by users.
-
Set authentication options.
For information, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
-
-
Oracle BI Presentation Services Administration — Enables you to set privileges for users to access features and functions such as editing views and creating agents and prompts.
-
Oracle BI Presentation Services — Enables you to assign permissions for objects in the Oracle BI Presentation Catalog.
In previous releases, you could assign permissions to objects from the Presentation Services Administration pages. In this release, you set permissions either in the Catalog Manager or the Catalog page of Presentation Services. See Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for information on assigning permissions in Presentation Services.
-
Catalog Manager — Enables you to set permissions for Oracle BI Presentation Catalog objects. For information on the Catalog Manager, see "Configuring and Managing the Oracle BI Presentation Catalog" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Note:
Security Administrators should advise report users to not edit Subject Area security privileges within BI EE Answers. Data security should be enforced by the Security Administrator.D.1.2 What Are the Security Goals in Oracle BI Presentation Services?
When maintaining security in Presentation Services, you must ensure the following:
-
Only the appropriate users can sign in and access Presentation Services. You must assign sign-in rights and authenticate users through the BI Server.
Authentication is the process of using a user name and password to identify someone who is logging on. Authenticated users are then given appropriate authorization to access a system, in this case Presentation Services. Presentation Services does not have its own authentication system; it relies on the authentication system that it inherits from the BI Server.
All users who sign in to Presentation Services are granted the AuthenticatedUser Role and any other roles that they were assigned in Fusion Middleware Control.
For information about authentication, see Section 1.3, "About Authentication".
-
Users can access only the objects that are appropriate to them. You apply access control in the form of permissions, as described in Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.
-
Users have the ability to access features and functions that are appropriate to them. You apply user rights in the form of privileges. Example privileges are "Edit systemwide column formats" and "Create agents."
Users are either granted or denied a specific privilege. These associations are created in a privilege assignment table, as described in Section D.2.3, "Managing Presentation Services Privileges."
You can configure Oracle Business Intelligence to use the single sign-on feature from the web server. Presentation Services can use this feature when obtaining information for end users. For complete information on single sign-on, see Chapter 4, "Enabling SSO Authentication".
D.1.3 How Are Permissions and Privileges Assigned to Users?
When you assign permissions and privileges in Presentation Services, you can assign them in one of the following ways:
-
To application roles — This is the recommended way of assigning permissions and privileges. Application roles provide much easier maintenance of users and their assignments. An application role defines a set of permissions granted to a user or group that has that role in the system's identity store. An application role is assigned in accordance with specific conditions. As such, application roles are granted dynamically based on the conditions present at the time authentication occurs.
See Section 1.4.1, "About Application Roles" for information on application roles.
-
To individual users — You can assign permissions and privileges to specific users, but such assignments can be more difficult to maintain and so this approach is not recommended.
-
To Catalog groups — This approach is not recommended, but is maintained for backward compatibility with previous releases only.
See Section D.2.2, "Working with Catalog Groups" for information on Catalog groups.
D.2 Using Oracle BI Presentation Services Administration Pages
You can use the Administration pages in Oracle BI Presentation Services to perform the tasks that are described in the following sections:
D.2.1 Understanding the Administration Pages
The main Administration page contains links that allow you to display other administration pages for performing various functions, including those related to users in Presentation Services. You can obtain information about all these pages by clicking the Help button in the upper-right corner.
Note:
Use care if multiple users have access to the Administration pages, because they can overwrite each other's changes. Suppose UserA and UserB are both accessing and modifying the Manage Privileges page in Presentation Services Administration. If UserA saves updates to privileges while UserB is also editing them, then UserB's changes are overwritten by those that UserA saved.D.2.2 Working with Catalog Groups
While you can continue to use Catalog groups, it is recommended that you move to the use of application roles rather than Catalog groups for organizing users. For more information, see "Migrating Catalog Groups to Application Roles".
In previous releases, Catalog groups were used for organizing users. Catalog group membership was used to determine the permissions and privileges that are associated with a user, either by explicit assignment or inheritance. In this release, Catalog groups have the following characteristics:
-
Are referred to as Catalog groups.
-
Can contain users, application roles, or other Catalog groups.
-
Exist only for the purposes of compatibility with previous releases and only with Presentation Services.
-
No longer have their own passwords.
Presentation Services administrators must ensure that the names of Catalog groups are different from any user IDs that are used to log in to Oracle BI Presentation Services. If a user and a Catalog group share the same name, then the user receives an Invalid Account message when attempting to log in to Oracle BI Presentation Services.
This section contains the following topics:
D.2.2.1 Migrating Catalog Groups to Application Roles
Although Catalog groups continue to function as in previous releases, they are not being supported in future releases. Oracle recommends that you start to migrate your Catalog groups to application roles now. Once you have migrated your Catalog groups to application roles, you must manually remove them from the Catalog.
This section explains how to migrate your Catalog groups from the Catalog to application roles, and remove them from the Catalog:
-
Section D.2.2.1.2, "Migrating Catalog Groups to Application Roles"
-
Section D.2.2.1.3, "Migrating Catalog Groups to Application Roles During Migration From 11g to 12c"
D.2.2.1.1 Generating Catalog Groups reports
Before migrating Catalog groups, run reports that identify:
-
Current Catalog groups and their members.
-
Privileges that reference Catalog groups.
-
Catalog paths that use or reference the Catalog groups.
To generate Catalog group reports:
-
Determine Catalog groups and membership Information.
Enter the following command:
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "Accounts" -accounts "group;;*" -fields "Account Name:Group Members" [-jaznFormat] [-excludeJaznHeader] [-expandGroups]
Generates a list of Catalog groups and their associated members within each group either in plain text or Jazn format.
Where:
-
jaznFormat
Generates a Jazn-formatted output file (used for importing new roles that are converted from existing groups).
-
excludeJaznHeader
Generates Jazn file without the header, so that you can insert the contents into an existing Jazn file.
-
expandGroups
Expands and lists the members of child Catalog groups or just lists the application role name.
-
-
Determine Catalog groups used in privileges that you maintain in the Presentation Services Manage Privileges page (see Section 2.6.3, "Setting Presentation Services Privileges for Application Roles").
Enter the following command:
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -folder /system/privs -type "Security ACL" -accountsInPrivilege "group;;*" -fields "Path:Privilege"
Generates a list of privileges that reference Catalog groups.
-
Determine paths of Catalog objects that contain references to Catalog groups.
Enter the following command:
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "All" -accountsInACL "group;;*" -fields "Path:ACL"
Generates a list of catalog paths that use or reference the Catalog groups.
D.2.2.1.2 Migrating Catalog Groups to Application Roles
This section describes how to migrate Catalog groups to Application roles.
Note:
Because Catalog groups can inherit permissions from the parent, and application roles cannot, there is no direct mapping between Catalog groups and application roles.Please review the following sections for additional information on the behavioral differences that can occur when groups are replaced with application roles:
-
Section D.3.1, "Rules for Determining a User's Privileges or Permissions"
-
Section D.3.2, "Example of Determining a User's Privileges with Application Roles"
-
Section D.3.3, "Example of Determining a User's Permissions with Application Roles"
-
Section D.3.4, "Example of Determining a User's Privileges with Deprecated Catalog Groups"
-
Section D.3.5, "Example of Determining a User's Permissions with Deprecated Catalog Groups"
When a Catalog object contains one or more Catalog groups, an automatic conversion from a group to role is error prone and may need manual intervention. During the migration we attempt to identify and log all potential security gaps, and recommend which Catalog objects would need to be examined further for potential security issues.
To migrate Catalog groups to application roles:
-
Identify the top level catalog folder from the following page.
For example:
http://example.com:9402/analytics/saw.dll?Admin
-
Stop Presentation Services, navigate to:
DOMAIN_HOME/bitools/bin/
For example, on UNIX, run the following command:
./stop.sh
-
Backup the catalog, because migration changes cannot be reversed.
Use a tool such as tar or zip.
-
Migrate Catalog groups to application roles and export groups to a Jazn file format.
Optionally control whether the new application roles are prefixed with '_GRP2ROLE_'.
Enter the following command:
runcat.cmd/runcat.sh -cmd migrateWebcatGroupsToApproles -offline<catalog path> -outputFile <output JAZN File> [-noGroupPrefix]
-
Generates a Jazn file that you use to import the new roles.
-
Removes the catalog groups and replaces them with application roles during the upgrade.
-
Prefixes the new application roles unless you specify the -noGroupPrefix.
-
Note:
The migration log file can highlight the security gap during the migration as follows:When multiple catalog groups have a parent/child relationship, it is flagged as a potential object that needs closer scrutiny and perhaps manual intervention. See ORACLE_HOME/user_projects/domains/bi/servers/obips1/logs/ migratewebcatgroups_<timestamp>.log file for objects that may have security gaps.The file format is <Object path> for the group names that have a parent/child relationship.
D.2.2.1.3 Migrating Catalog Groups to Application Roles During Migration From 11g to 12c
Use this task when you move from 11g to 12c.
To migrate Catalog groups to application roles during migration from 11g to 12c:
-
Stop Presentation Services.
-
Backup the catalog prior to executing this command because migration changes cannot be reversed.
Use a tool such as tar or zip.
-
Determine Catalog groups and membership Information.
Enter the following command:
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "Accounts" -accounts "group;;*" -fields "Account Name:Group Members" [-jaznFormat] [-excludeJaznHeader] [-expandGroups] [-noGroupPrefix]
Generates a list of Catalog groups and their associated members within each group either in plain text or Jazn format.
Where:
-
jaznFormat
Generates a Jazn-formatted output file (used for importing new roles that are converted from existing groups).
-
excludeJaznHeader
Generates Jazn file without the header, so that you can insert the contents into an existing Jazn file.
-
expandGroups
Expands and lists the members of child Catalog groups or just lists the application role name.
-
noGroupPrefix
Prefixes the new application roles unless you specify the -noGroupPrefix.
-
-
Migrate Catalog groups to application roles (during upgrade from 11g to 12c).
Enter the following command:
runcat.cmd/runcat.sh -cmd upgradeCatalog -offline<catalog path> [-migrateGroups <withPrefix | noPrefix>]
-
Optionally removes the catalog groups and replaces them with application roles during the upgrade.
-
Optionally determines if the newly replaced application roles will use a prefix or not.
-
-
Import the Jazn file created in step3 "Determine Catalog groups and membership Information." back into your security system.
D.2.2.1.4 Removing Migrated Application Roles
To remove migrated application roles:
For information, see "Deleting an Application Role".
D.2.2.2 Creating Catalog Groups
Oracle strongly recommends that you do not create any new Catalog groups in Release 12.2.1 and later.
Although Catalog groups continue to function as in previous releases, they are not being supported in future releases. Oracle recommends that you start to migrate your Catalog groups to application roles now. Once you have migrated your Catalog groups to application roles, you must go to each and every object and then right click to remove the Catalog groups manually.
To create Catalog groups:
-
From the Home page in Presentation Services, select Administration.
-
Click the Manage Catalog Groups link.
-
Click Create a New Catalog Group.
-
In the Add Group dialog, enter a name for the group.
-
Use the shuttle control to select the Catalog groups, users, and application roles to include in this group.
Tip:
It is best practice to not include application roles in Catalog groups, to avoid complex group inheritance and maintenance situations. In particular do not add the AuthenticatedUser Role to any other Catalog groups that you create. This ensures that only the desired Catalog groups (and users) have the specified permissions and privileges, by preventing users or authenticated users from unintentionally inheriting permissions and privileges from another Catalog group. -
Click OK.
D.2.2.3 Deleting Catalog Groups
To delete Catalog groups:
This only removes the groups, but not the internal references from privileges and other catalog objects.
-
From the Home page in Presentation Services, select Administration.
-
Click the Manage Catalog Groups link.
-
On the Manage Catalog Groups page, select the one or more groups to delete.
To help you locate the group that you want, enter text in the Name field and click Search.
-
Click Delete Selected Groups.
-
Click OK to confirm the deletion.
D.2.2.4 Editing Catalog Groups
To edit Catalog groups:
-
From the Home page in Presentation Services, select Administration.
-
Click the Manage Catalog Groups link.
-
On the Manage Catalog Groups page, select the group to edit.
To help you locate the group that you want, enter text in the Name field and click Search.
You can click the More Groups button to display the next 25 groups in the list.
-
In the Edit Group dialog, change the name or add or remove application roles, Catalog groups, and users.
-
Click OK.
D.2.3 Managing Presentation Services Privileges
This section contains the following topics about Presentation Services privileges:
-
Section D.2.3.1, "What Are Presentation Services Privileges?"
-
Section D.2.3.2, "Setting Presentation Services Privileges for Application Roles"
-
Section D.2.3.3, "Default Presentation Services Privilege Assignments"
D.2.3.1 What Are Presentation Services Privileges?
Presentation Services privileges control the rights that users have to access the features and functionality of Presentation Services. Privileges are granted or denied to specific application roles, individual users, and Catalog groups using a privilege assignment table.
Like permissions, privileges are either explicitly set or are inherited through role or group membership. Explicitly denying a privilege takes precedence over any granted, inherited privilege. For example, if a user is explicitly denied access to the privilege to edit column formulas, but is a member of an application role that has inherited the privilege, then the user cannot edit column formulas.
Privileges are most commonly granted to the BIContentAuthor or BIConsumer roles. This allows users access to common features and functions of Presentation Services. While you can continue to grant privileges to Catalog groups, it is recommended that you switch the grants to application roles.
D.2.3.2 Setting Presentation Services Privileges for Application Roles
You can set Presentation Services privileges for application roles, individual users, and Catalog groups from the Presentation Services Administration Manage Privileges page.
For more information, see Section 2.6.3, "Setting Presentation Services Privileges for Application Roles".
D.2.3.3 Default Presentation Services Privilege Assignments
Table D-1 lists the privileges that you can manage, along with the application role that is granted access to that privilege by default. For additional information, reference links are also provided in the table.
These privileges apply to the Oracle Business Intelligence infrastructure. If your organization uses prebuilt applications, then some privileges might be preconfigured. For more information, see the documentation for the application.
Note:
When building KPIs, KPI watchlists, or within Oracle Scorecard and Strategy Management, a combination of privileges might be required to perform specific tasks. See Section D.2.3.3.4, "Identifying Privileges for KPIs, KPI Watchlists, and Scorecarding."Note:
To login to an Oracle BI EE connection from SmartView you must have at least the following BI Presentation Service privileges (for more information, see Table D-1):-
Access SOAP
-
Access CatalogService Service
-
Access SecurityService Service
-
Access Oracle BI for MS Office
You must also have access to open the Shared Catalog folder.
Table D-1 Privileges and Default Settings for the Oracle Business Intelligence Infrastructure
D.2.3.3.1 Access to Oracle BI Enterprise Edition Actions
You must set the Action privileges, which determine whether the Actions functionality is available to users and specify which user types can create Actions. The following list describes these privileges:
-
Create Navigate Actions — Determines which users can create a Navigate action type. The sessions of users who are denied this privilege do not contain any of the user interface components that allow them to create Navigate Actions. For example, if a user is denied this privilege and chooses to create an action from the Oracle BI Enterprise Edition global header, the dialog where the user selects an action type does not include the Navigate Actions options (Go to BI Content, Go to a Web Page, and so on). However, users who are denied this privilege can add saved actions to analyses and dashboards. And, users who are denied this privilege can execute an action from an analysis or dashboard that contains an action.
-
Create Invoke Actions — Determines which users can create an Invoke action type. The sessions of user who are denied this privilege do not contain any of the user interface components that allow them to create Invoke Actions. For example, if a user is denied this privilege and chooses to access the agent editor's Actions tab and clicks the Add New Action button, the dialog where the user selects the action type does not include the Invoke Actions options (Invoke a Web Service, Invoke an HTTP Request, and so on). However, users who are denied this privilege can add saved actions to analyses and dashboards. And, users who are denied this privilege can execute an action from an analysis or dashboard that contains an action.
-
Save Actions Containing Embedded HTML — Determines which users can embed HTML code in the customization of web service action results. Use care in assigning this privilege, because it poses a security risk to allow users to run HTML code.
D.2.3.3.2 Access to Oracle BI for Microsoft Office Privilege
The Access to Oracle BI for Microsoft Office privilege shows the following option for the Download BI Desktop Tools link in the Get Started area of the Oracle BI EE Home page:
-
Oracle BI for MS Office: Downloads the installation file for the Oracle BI Add-in for Microsoft Office.
The Access to Oracle BI for Microsoft Office privilege does not affect the display of the Copy link for analyses. The link is always available there.
The location of the installation file to download for Oracle BI for Microsoft Office is specified by default in the BIforOfficeURL element in the instanceconfig.xml file. For more information on using Oracle BI for Microsoft Office and the Copy option, see Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.
D.2.3.3.3 Save Content with HTML Markup Privilege
By default, Presentation Services is secured against cross-site scripting (XSS). Securing against XSS escapes input in fields in Presentation Services and renders it as plain text. For example, an unscrupulous user can use an HTML field to enter a script that steals data from a page.
By default, end users cannot save content that is flagged as HTML; instead only administrators who have the Save Content with HTML Markup privilege can save content that contains HTML code. Users that have the Save Content with HTML Markup privilege can save an image with the "fmap" prefix. If users try to save an image with the "fmap" prefix when they do not have this privilege assigned, then they see an error message.
Users with this privilege can also save mission and vision statements in Oracle Scorecard and Strategy Management.
D.2.3.3.4 Identifying Privileges for KPIs, KPI Watchlists, and Scorecarding
The ability to perform certain tasks when building KPIs, and KPI watchlists, or within Oracle Scorecard and Strategy Management (such as, viewing or creating scorecards or contacting owners) generally requires a combination of privileges. Table D-2, Table D-3, and Table D-4 list the following information for KPIs, KPI watchlists, and Oracle Scorecard and Strategy Management, respectively:
-
Task Object (for example, Action link or KPI chart)
-
Task (for example, "Contact owner from a dashboard" or "Follow a link in the Scorecard editor")
-
Privileges required to perform the task (for example, "Delivers - Create Agents" or "Access - Access to Dashboards"). You must have each privilege listed to perform the specific task.
The privileges required to perform these tasks have been grouped into sets where applicable, and the set name has been included (rather than the individual privileges) along with any additional required privileges. The set names and privileges included within each set are:
-
Edit_scorecard_set1
Privileges include:
-
Access - Access to Scorecard
-
Scorecard - Create/Edit Scorecards
-
-
View_or_edit_scorecard_set2
Privileges include:
-
Access - Access to Scorecard
-
Scorecard - Create/Edit Scorecards or Scorecard - View Scorecards
-
-
View_KPI_watchlist_on_dashboard_set3
Privileges include:
-
Access - Access to Dashboards
-
Access - Access to Scorecard
-
-
Edit_KPI_with_KPI_Builder_set4
Privileges include:
-
Access - Access to KPI Builder
-
Scorecard - Create/Edit KPIs
-
Subject Area - <name of subject area>
-
-
Edit_KPI_watchlist_with_standalone_KPI_watchlist_editor_set5
Privileges include:
-
Access - Access to KPI Builder
-
Scorecard - Create/Edit KPIs
-
View_KPI_watchlist_in_standalone_KPI_watchlist_editor_set6
Privileges include:
-
Access - Access to Scorecard
-
Scorecard - Create/Edit Scorecards or Scorecard - View Scorecards
-
Table D-2 lists the combination of privileges that are required for KPI tasks.
Table D-2 Privileges Required for KPI Tasks
| Task Object | Task | Privileges Required to Perform the Task |
|---|---|---|
|
Action link |
Create, edit, or delete on a KPI within the Scorecard editor using the KPI editor1 tab |
|
|
Action link |
Create, edit, or delete from within the KPI editor |
|
|
Agent |
Create an agent for a KPI within the Scorecard editor |
|
|
Business owner |
Modify within the Scorecard editor using the KPI editor tab |
|
|
Business owner |
Modify from within the KPI editor |
|
|
KPI |
Create or edit within the Scorecard editor using the KPI editor tab |
Note that you must have read/write permission on the folder for which you create the KPI, and at least read permission on all ancestor directories. |
|
KPI |
Create, edit, or view from within the KPI editor Note that there is no read-only mode in the KPI editor. |
Note that you must have read/write permission on the folder for which you create the KPI and at least read permission on all ancestor directories. |
|
KPI |
Open to see an Answers analysis from the Oracle BI EE Home page, Favorites list, or Catalog browser |
No specific Access, Scorecard, or Subject area privileges are required. |
|
KPI dimensioned target value (target setting) |
Edit within the KPI watchlist on a dashboard |
|
|
KPI dimensioned target value (target setting) |
Edit within a scorecard view2 on a dashboard |
|
|
Related document |
Add, edit, or delete a related document from within the KPI editor |
|
|
Related document |
Add, edit, or delete a related document within the Scorecard editor using the KPI editor tab |
Table D-3 lists the combination of privileges that are required for KPI watchlist tasks.
Table D-3 Privileges Required for KPI Watchlist Tasks
| Task Object | Task | Privileges Required to Perform the Task |
|---|---|---|
|
<Device> (for example, email, pager, or digital phone) |
Contact owner from a KPI watchlist on a dashboard |
|
|
<Device> |
Contact owner from within the standalone KPI watchlist editor3 |
|
|
Action link |
Invoke from a KPI watchlist on a dashboard |
Note that you must enable pop-ups in your browser. |
|
Action link |
Invoke from within the standalone KPI watchlist editor |
|
|
Analyze link |
Follow an analyze link from a KPI watchlist view on a dashboard |
Note that you must enable pop-ups in your browser. |
|
Analyze link |
Follow an analyze link from within the standalone KPI watchlist editor |
Note that you must enable pop-ups in your browser. |
|
Annotation |
Add from a KPI watchlist on a dashboard |
|
|
Annotation |
Add from within the standalone KPI watchlist editor |
|
|
Annotation |
View from a KPI watchlist on a dashboard |
|
|
Annotation |
View from within the standalone KPI watchlist editor |
|
|
Business owner |
Modify the business owner of a KPI watchlist from within the standalone KPI watchlist editor |
|
|
Business owner |
View the business owner in a KPI watchlist from within the standalone KPI watchlist editor |
|
|
KPI chart |
View a KPI chart from a KPI watchlist on a dashboard |
|
|
KPI chart |
View a KPI chart from within the standalone KPI watchlist editor |
|
|
KPI dimensioned target value (target setting) |
Edit a KPI's dimensioned target value in the KPI watchlist within the Scorecard editor |
|
|
KPI dimensioned target value (target setting) |
Edit a KPI's dimensioned target value in the KPI watchlist from within the standalone KPI watchlist editor |
|
|
KPI watchlist |
Add to a dashboard |
|
|
KPI watchlist |
Create or edit within the Scorecard editor |
|
|
KPI watchlist |
Create or edit from within the standalone KPI watchlist editor |
Note that you must have read/write permission on the folder under which you create the KPI watchlist and at least read permission on all ancestor directories. |
|
KPI watchlist |
Open in read-only from within the standalone KPI watchlist editor |
|
|
KPI watchlist |
View on a dashboard |
|
|
Related document |
Follow a related document link from within the standalone KPI watchlist editor |
|
|
Related document |
Add, edit, or delete a related document from within the standalone KPI watchlist editor |
|
|
Related document |
Add, edit, or delete a related document for a KPI watchlist |
|
Table D-4 lists the combination of privileges that are required for scorecard and scorecard object tasks.
Table D-4 Privileges Required for Scorecard and Scorecard Object Tasks
| Task Object | Task | Privileges Required to Perform the Task |
|---|---|---|
|
<Device> (for example, email, pager, or digital phone) |
Contact owner in a scorecard view on a dashboard |
|
|
<Device> |
Contact owner within the Scorecard editor |
|
|
Action link |
Invoke in a scorecard view on a dashboard |
Note that you must enable pop-ups in your browser. |
|
Action link |
Invoke within the Scorecard editor |
|
|
Action link on an object in the Strategy or Initiatives panes |
Create, edit, or delete within the Scorecard editor |
|
|
All scorecard nodes4, views, and documents (excludes KPI editor) |
View in read-only within the Scorecard editor |
|
|
Analyze link |
Follow an analyze link in a scorecard view on a dashboard |
Note that you must enable pop-ups in your browser. |
|
Analyze link |
Follow an analyze link within the Scorecard editor |
Note that you must enable pop-ups in your browser. |
|
Annotation |
Add in a scorecard view on a dashboard |
|
|
Annotation |
Add in a scorecard view within the Scorecard editor |
|
|
Annotation |
View in a scorecard view on a dashboard |
|
|
Annotation |
View within the Scorecard editor |
|
|
Business owner |
Modify within the Scorecard editor |
|
|
Business owner |
View within the Scorecard editor |
|
|
Causal linkage |
Create, edit, or delete within the Scorecard editor |
|
|
Dimensioned status override of a scorecard node |
Override a KPI's dimensioned status (or cancel an override) from a scorecard view on a dashboard |
Note that you must also be the KPI's business owner to override the status that is set in the KPI editor. |
|
Dimensioned status override of a scorecard node |
Override a KPI's dimensioned status (or cancel an override) within the Scorecard editor |
Note that you must also be the KPI's business owner to override the status that is set in the KPI editor. |
|
Dimensioned status override of a scorecard node |
View a KPI's dimensioned status in a scorecard view on a dashboard |
|
|
Dimensioned status override of a scorecard node |
View a KPI's dimensioned status in a scorecard view within the Scorecard editor |
|
|
Filter |
Add a user to the filter in a scorecard smart watchlist within the Scorecard editor |
|
|
Filter |
Filter on a user in the scorecard smart watchlist on a dashboard |
|
|
Filter |
Filter on a user in the scorecard smart watchlist within the Scorecard editor |
|
|
Initiatives node5 |
Create, edit, or delete within the Scorecard editor using the Initiatives tab or KPI Details tab |
|
|
KPI chart |
View in a scorecard view on a dashboard |
|
|
KPI chart |
View within the Scorecard editor |
|
|
Mission or vision statement |
Create or edit within the Scorecard editor |
|
|
Permissions dialog |
Modify within the Scorecard editor |
|
|
Perspective |
Create, edit, or delete within the Scorecard editor |
|
|
Related document |
Add, edit, or delete for a scorecard node or scorecard view within the Scorecard editor |
|
|
Related document |
Follow a related document link within the Scorecard editor |
|
|
Scorecard |
Create |
Note that you must have read/write permission on the scorecard folder and at least read permission on all ancestor directories. |
|
Scorecard |
Edit using the Scorecard editor |
Note that you must have read/write permission on the scorecard folder and at least read permission on all ancestor directories. |
|
Scorecard view |
Add to a dashboard |
|
|
Scorecard view (excludes mission and vision statements and KPI watchlists) |
Create, edit, or delete within the Scorecard editor |
|
|
Scorecard view |
View on a dashboard |
|
|
Settings dialog |
Modify (or view) settings |
|
|
Strategy node6 |
Create, edit, or delete within the Scorecard editor using the Objective tab or KPI Details tab |
|
-
The KPI editor is also known as the KPI Builder.
-
A scorecard view (also known as a "scorecard document") is an Oracle BI EE catalog object which meets the following criteria:
-
Displays in the Scorecard Documents pane within the Scorecard editor. See Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for additional information.
-
Is tied to and can only be edited in the specific scorecard where it was created.
-
Displays the scorecard's strategy and initiative information.
-
Consists of the following view types:
-
Cause and effect map
-
Custom view
-
Mission statement
-
Smart watchlist
-
Strategy map
-
Strategy tree
-
Strategy contribution wheel
-
Vision statement
-
-
-
The standalone KPI watchlist editor is the KPI watchlist editor used outside of the Scorecard editor. In other words, it is not embedded within a Scorecard editor tab.
-
Scorecard node is an objective or initiative that belongs to the Strategy pane tree or Initiatives pane tree of a scorecard, or a KPI belonging to an initiative or objective within these panes, respectively.
-
Initiatives node is an initiative or KPI within the Initiatives pane. See Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for additional information.
-
Strategy node is an objective or KPI within the Strategy pane. See Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for additional information.
D.2.4 Managing Sessions in Presentation Services
Using the Session Management page in Presentation Services Administration, you can view information about active users and running analyses, cancel requests, and clear the cache.
To manage sessions in Presentation Services:
-
From the Home page in Presentation Services, select Administration.
-
Click the Manage Sessions link.
The Session Management screen is displayed with the following tables:
-
The Sessions table, which gives information about sessions that have been created for users who have logged in:
-
The Cursor Cache table, which shows the status of analyses:
-
To cancel all running requests:
-
Click Cancel Running Requests.
-
Click Finished.
To cancel one running analysis:
-
In the Cursor Cache table, identify the analysis and click the Cancel link in the Action column.
The user receives a message indicating that the analysis was canceled by an administrator.
To clear the web cache:
-
In the Cursor Cache table, identify the analysis and click Close All Cursors.
-
Click Finished.
To clear the cache entry associated with an analysis:
-
In the Cursor Cache table, identify the analysis and click the Close link in the Action column.
To view the query file for information about an analysis:
-
In the Cursor Cache table, identify the analysis and click the View Log link.
Note:
Query logging must be turned on for data to be saved in this log file.
D.3 Determining a User's Privileges and Permissions in Oracle BI Presentation Services
Oracle BI Presentation Services privileges and Oracle BI Presentation Services Catalog item permissions, use an Access Control List (ACL) to control who has privilege to access Presentation Services functionality and what permissions any given user can have on Presentation Services Catalog items. Privileges are set using the Administration pages in Oracle BI Presentation Services. Permissions are set for Presentation Services Catalog objects through the Analytics user interface, or the Catalog Manager user interface.
When you try to access functionality in Presentation Services, the appropriate privilege is checked; for example, to view the Oracle Business Intelligence page you must have the Access to Answers privilege. Also, when you try to perform any action on a Presentation Services Catalog item, that item's permissions are checked; for example, to view an item in Oracle Business Intelligence, the item's permissions are checked to see if you have read access.
There are 3 types of records that may be added to an ACL:
-
Individual user records
It is difficult to administer individual user records especially when there might be thousands of users, and hundreds of thousands of Catalog items.
-
10g Catalog group records
Catalog groups exist purely for backwards compatibility, and are not recommended. They should not be used, instead you should change to using application roles.
-
11g application roles records
These are the recommended way of managing ACLs.
Oracle Business Intelligence determines user access by sequentially checking 3 types of records. A user's effective privileges or permissions are deduced using the ACL records, looking for an explicit record for the user (if there is one); then looking for any records with the Catalog groups, of which the user is directly and indirectly a member; and then looking for any records with application roles granted to the user either explicitly or implicitly.
This section contains the following topics:
-
Section D.3.1, "Rules for Determining a User's Privileges or Permissions"
-
Section D.3.2, "Example of Determining a User's Privileges with Application Roles"
-
Section D.3.3, "Example of Determining a User's Permissions with Application Roles"
-
Section D.3.4, "Example of Determining a User's Privileges with Deprecated Catalog Groups"
-
Section D.3.5, "Example of Determining a User's Permissions with Deprecated Catalog Groups"
D.3.1 Rules for Determining a User's Privileges or Permissions
The following tasks describe the sequential checks completed to determine a user's effective privileges and permissions.
Note:
Step 1 takes precedence over Step 2, which takes precedence over Step 3, which takes precedence over Step 4, which takes precedence over Step 5.Note:
Within an individual step, a privilege ACL record that is Denied always takes precedence over any other grants. Similarly, within an individual step, a permission ACL record that has No Access always takes precedence over any access grant.Semantically, the privilege Denied is the same as the permission No Access, and so the term deny will be used interchangeably for both privileges and permissions.
D.3.1.1 Task 1 - Check for an explicit record for this user
The following sequence represents the checks completed for a user record.
-
If there is an explicit record for this user, then return that access. Done.
-
If there is no explicit record for this user. Go to Task 2 - Check for records for this user's Catalog groups (deprecated behavior for 10g backwards compatibility only).
D.3.1.2 Task 2 - Check for records for this user's Catalog groups (deprecated behavior for 10g backwards compatibility only)
The following sequence represents the checks completed for a user's Catalog groups.
-
Get the set of all Catalog groups this user is directly, explicitly in.
This set does not include Catalog groups that this user is implicitly in.
This set includes:
-
Catalog groups assigned through the Presentation Services Administration Page.
-
Catalog groups assigned through the WEBGROUPS BI session variable.
-
Any Catalog group that has an application role as a member, where that application role has been granted (either explicitly or implicitly) to this user.
Note:
This functionality was initially provided to help migration of 10g Catalog groups to 11g application roles, rather than force immediate conversion of all Catalog groups to application roles.
-
-
Check for any ACL record that matches any of the current set of Catalog groups as follows:
-
If there are any records that deny access, then return access denied. Done.
-
Else, if there are any records that grant access, return the union of all those access grants. For example, if one Catalog group has read access, and another Catalog group has write access, then the user has read and write access. Done.
-
Else, no records matched the current set of Catalog groups.
-
-
Get the parent set of all Catalog groups of the current set of Catalog groups. In other words, get all Catalog groups that the current set of Catalog groups are themselves members of explicitly. This parent set becomes the new current set of Catalog groups.
-
If the parent set is not empty, go to "Check for any ACL record that matches any of the current set of Catalog groups as follows:".
-
Thus, explicit Catalog groups take precedence over (override) implicit Catalog groups.
-
Similarly, implicit "parent" Catalog groups take precedence over implicit "grandparent" Catalog groups; implicit "grandparent" Catalog groups take precedence over implicit "great-grandparent" Catalog groups; and so on.
Note:
The logic for permission inheritance for Catalog groups is different to the logic for permission inheritance for application roles.
-
-
Else there were no records for this user's Catalog groups. Go to Task 3 - Check records for this user's application roles.
D.3.1.3 Task 3 - Check records for this user's application roles
The following sequence represents the checks completed for a user's application roles.
-
Get all the application roles for this user, including both direct, explicit application roles and indirect, implicit application roles.
For example, if a user is explicitly granted the BI Author application role, then the user also implicitly has the BI Consumer application role too.
-
Check for any ACL record that matches any of the set of application roles.
-
If any records deny access, then return access denied. Done.
-
Else, if any records grant access, return the union of all those access grants. So if one application role had read access, and another application role had write access, then the user has read and write access. Done.
-
Else there are no records for this user's application roles.
-
-
Else there were no records for this user's application roles. Go to Task 4 - Fall back default behavior.
D.3.1.4 Task 4 - Fall back default behavior
The following sequence represents the checks completed for a specific application role called Authenticated User.
-
If there is a record for the authenticated user application role, return that record's access. Done.
Note:
The Authenticated User application role is deliberately not included in the list of application roles for a user in Task 3 - Check records for this user's application roles, even though that user does technically have this application role too. -
Else there is no record for the special application role. Go to Task 5 - No matching records at all.
D.3.1.5 Task 5 - No matching records at all
Return access denied. Done.
D.3.2 Example of Determining a User's Privileges with Application Roles
Figure D-1 shows an example of how privileges are determined with application roles. At the top of the diagram is a rectangle labelled User1, which specifies that User1 has been explicitly given the application roles Executive and BI Author. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents the Executive role and one on the right that represents the BI Author role.
-
The Executive role rectangle specifies that Executive is granted the Access to Administration privilege, and that the application roles Finance and Sales have in turn been given to Executive.
-
The BI Author role rectangle specifies that BI Author is granted the Catalog privilege, is Denied the Agents privilege, and that the application role BI Consumer has in turn been given to BI Author.
Attached beneath the Executive Role rectangle are two more rectangles - one on the left that represents the Finance role and one on the right that represents the Sales role:
-
The Finance Role rectangle specifies that the Finance role is granted the Scorecard privilege.
-
The Sales Role rectangle specifies that Sales is Denied the Access to Administration privilege and granted the Access to Answers privilege.
And finally, attached beneath the BI Author Role rectangle is a rectangle that represents the BI Consumer role:
-
The BI Consumer Role rectangle specifies that BI Consumer is granted the Catalog privilege and is granted the Agents privilege.
Figure D-1 Example of Determining a User's Privileges Using Application Roles
Description of ''Figure D-1 Example of Determining a User's Privileges Using Application Roles''
In this example:
-
User1 explicitly has the Executive role, and thus implicitly has Finance role and also Sales role.
-
User1 also explicitly has the BI Author role, and thus also implicitly has BI Consumer role.
-
So User1's flattened list of application roles is Executive, BI Author, Finance, Sales and BI Consumer.
-
The effective privileges from Executive Role are Denied Administration privilege, granted Scorecard privilege, and granted Answers privilege. The Sales' Denied Administration privilege takes precedence over Executive's granted privilege, as Deny always takes precedence.
-
The effective privileges from the BI Author role are granted Catalog privilege, and Denied Agents privilege. The BI Author's Denied Agents privilege takes precedence over BI Consumer's granted, as deny always takes precedence.
The total privileges granted to User1 are as follows:
-
Denied Administration privilege, because the privilege is specifically denied for Sales.
-
Granted Scorecard privilege.
-
Granted Answers privilege.
-
Granted Catalog privilege.
-
Denied Agents privilege, because the privilege is specifically denied for BI Author.
D.3.3 Example of Determining a User's Permissions with Application Roles
Figure D-2 shows an example of how permissions are determined with application roles. At the top of the diagram is a rectangle labelled User1, which specifies that User1 has been explicitly given the application roles Executive and BI Author. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Executive Role and one on the right that represents BI Author Role.
-
The Executive Role rectangle specifies that Executive has no access to DashboardA, and that the application roles Finance and Sales have in turn been given to Executive.
-
The BI Author Role rectangle specifies that BI Author role has open access to DashboardD, has no access to DashboardE, and that the BI Consumer role has in turn been given to BI Author.
Attached beneath the Executive Role rectangle are two more rectangles - one on the left that represents Finance role and one on the right that represents Sales role:
-
The Finance Role rectangle specifies that Finance role has open access to DashboardB.
-
The Sales Role rectangle specifies that Sales role has no access to DashboardA and full control of DashboardC.
And finally, attached beneath the BI Author Role rectangle is a rectangle that represents BI Consumer role:
-
The BI Consumer Role rectangle specifies that BI Consumer role has modify access to DashboardD and open access to DashboardE.
Figure D-2 Example of Determining a User's Permissions Using Application Roles
Description of ''Figure D-2 Example of Determining a User's Permissions Using Application Roles''
In this example:
-
User1 explicitly has Executive role, and thus implicitly has Finance role and also Sales role.
-
User1 also explicitly has BI Author role, and thus also implicitly has BI Consumer role.
-
So User1's flattened list of application roles is Executive, BI Author, Finance, Sales and BI Consumer.
-
The effective permissions from Executive role are no access to DashboardA, open access to DashboardB, and full control for DashboardC. Note Sales role's No Access to DashboardA takes precedence over Executive role's Open, as Deny always takes precedence.
-
The effective privileges from BI Author role are Open&Modify access to DashboardD, and No Access to DashboardE. Note BI Author role's No Access to DashboardE takes precedence over BI Consumer role's Open, as Deny always takes precedence.
The total permissions and privileges granted to User1 are as follows:
-
No Access to DashboardA, because access is specifically denied for Sales role.
-
Open Access to DashboardB.
-
Full Control for DashboardC.
-
Open&Modify access to DashboardD, the union of Role2's and Role5's access.
-
No Access to DashboardE, because access is specifically denied for BI Author role.
D.3.4 Example of Determining a User's Privileges with Deprecated Catalog Groups
Figure D-3 shows an example of how privileges are determined with Catalog groups. At the top of the diagram is a rectangle labelled User1, which specifies that User1 is an explicit member of the Catalog groups, Manager Group and Canada Group. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Manager Group and one on the right that represents Canada Group.
-
The Manager Group rectangle specifies that Manager Group is granted the Access to Administration privilege, and that the Manager Group is in turn itself a member of both Marketing Group and Sales Group.
-
The Canada Group rectangle specifies that Canada Group is granted the Catalog privilege, is denied the Agents privilege, and that the Canada Group is in turn itself a member of the Americas Group.
Attached beneath the Manager Group rectangle are two more rectangles - one on the left that represents Marketing Group and one on the right that represents Sales Group:
-
The Marketing Group rectangle specifies that Marketing Group is granted the Scorecard privilege.
-
The Sales Group rectangle specifies that Sales Group is denied the Access to Administration privilege and granted the Access to Answers privilege.
And finally, attached beneath the Canada Group rectangle is a rectangle that represents the Americas Group:
-
The Americas Group rectangle specifies that Americas Group is granted the Catalog privilege and is granted the Agents privilege.
Figure D-3 Example of Determining a User's Privileges Using Deprecated Catalog Groups
Description of ''Figure D-3 Example of Determining a User's Privileges Using Deprecated Catalog Groups''
In this example:
-
User1 is explicitly in the Manager Group, and thus is implicitly in the Marketing Group and Sales Group too.
-
User1 also is explicitly in the Canada Group, and thus is also implicitly in the Americas Group too.
-
So User1's initial list of Catalog groups is Manager Group and Canada Group. If required, User1's parent list of Catalog groups is Marketing Group, Sales Group and Americas Group. The grandparent list of Catalog groups is empty, as the Catalog group hierarchy is only two levels deep.
-
The effective privileges from the Manager Group are granted the Administration privilege, granted Scorecard privilege, and granted the Answers privilege. Note explicit Manager Group's record for Administration takes precedence over implicit Sale Group's record, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.
-
The effective privileges from the Canada group are granted the Catalog privilege, and denied Agents privilege. Note explicit Canada Group's records for both Catalog and Agents takes precedence over implicit Americas Group's records, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.
The total privileges granted to User1 are as follows:
-
Granted Access to Administration privilege, because the Manager Group takes precedence over Sales group.
-
Granted Scorecard privilege.
-
Granted Answers privilege.
-
Granted Catalog privilege, because Canada Group takes precedence over Americas Group.
-
Denied Agents privilege, because the Canada Group takes precedence over Americas.
D.3.5 Example of Determining a User's Permissions with Deprecated Catalog Groups
Figure D-4 shows an example of how permissions are determined with Catalog groups. At the top of the diagram is a rectangle labelled User1, which specifies that User1 is an explicit member of Catalog groups Manager Group and Canada Group. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Manager Group and one on the right that represents Canada Group.
-
The Manager Group rectangle specifies that Manager Group has open access to DashboardA, and that the Manager Group is in turn itself a member of both Marketing Group and Sales Group.
-
The Canada Group rectangle specifies that Canada Group has open access to DashboardD, has no access to DashboardE, and that the Canada Group is in turn itself a member of the Americas Group.
Attached beneath the Manager Group rectangle are two more rectangles - one on the left that represents Marketing Group and one on the right that represents Sales Group:
-
The Marketing Group rectangle specifies that Marketing Group has open access to DashboardB.
-
The Sales Group rectangle specifies that Sales Group has full control of DashboardC and no access to DashboardA.
And finally, attached beneath the Canada Group rectangle is a rectangle that represents the Americas Group:
-
The Americas Group rectangle specifies that Americas Group has Modify access to DashboardD and Open access to DashboardE.
Figure D-4 Example of Determining a User's Permissions Using Deprecated Catalog Groups
Description of ''Figure D-4 Example of Determining a User's Permissions Using Deprecated Catalog Groups''
In this example:
-
User1 is explicitly in the Manager Group, and thus is implicitly in the Marketing Group and Sales Group too.
-
User1 also is explicitly in the Canada Group, and thus is also implicitly in the Americas Group too.
-
So User1's initial list of Catalog groups is Manager Group and Canada Group. If required, User1's parent list of Catalog groups is Marketing Group, Sales Group and Americas Group. The grandparent list of Catalog groups is empty, as the Catalog group hierarchy is only two levels deep.
-
The effective permissions from the Manager Group are open access to DashboardA, open access to DashboardB, and full control of DashboardC. Note explicit Manager Group's record for DashboardA takes precedence over implicit Sale Group's record, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.
-
The effective permissions from the Canada group are open access to DashboardD, and no access to DashboardE. Note explicit Canada Group's records for both DashboardD and DashboardE takes precedence over implicit Americas Group's records, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.
The total privileges granted to User1 are as follows:
-
Open access to DashboardA, because the Manager group takes precedence over Sales group.
-
Open access to DashboardB.
-
Full control of DashboardC.
-
Open access to DashboardD, because the Canada group takes precedence over Americas group.
-
No access to DashboardE, because the Canada group takes precedence over Americas group.
D.4 Providing Shared Dashboards for Users
This section contains the following topics on providing shared dashboards for users:
D.4.1 Understanding the Catalog Structure for Shared Dashboards
The Oracle BI Presentation Catalog has two main folders:
-
My Folders — Contains the personal storage for individual users. Includes a Subject Area Contents folder where you save objects such as calculated items and groups.
-
Shared Folders — Contains objects and folders that are shared across users. Dashboards that are shared across users are saved in a Dashboards subfolder under a common subfolder under the /Shared Folders folder
Note:
If a user is given permission to an analysis in the Oracle BI Presentation Catalog that references a subject area to which the user does not have permission, then the BI Server still prevents the user from executing the analysis.D.4.2 Creating Shared Dashboards
After setting up the Oracle BI Presentation Catalog structure and setting permissions, you can create shared dashboards and content for use by others.
One advantage to creating shared dashboards is that pages that you create in the shared dashboard are available for reuse. Users can create their own dashboards using the pages from your shared dashboards and any new pages that they create. You can add pages and content as described in Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.
If you plan to allow multiple users to modify a shared default dashboard, then consider putting these users into an application role. For example, suppose that you create an application role called Sales and create a default dashboard called SalesHome. Of the 40 users that have been assigned the Sales application role, suppose that there are three who must have the ability to create and modify content for the SalesHome dashboard. Create a SalesAdmin application role, with the same permissions as the primary Sales application role. Add the three users who are allowed to make changes to the SalesHome dashboard and content to this new SalesAdmin application role, and give this role the appropriate permissions in the Oracle BI Presentation Catalog. This allows those three users to create and modify content for the SalesHome dashboard. If a user no longer requires the ability to modify dashboard content, then you can change the user's role assignment to Sales. If an existing Sales role user must have the ability to create dashboard content, then the user's role assignment can be changed to SalesAdmin.
For more information about creating shared dashboards, see 'Managing Dashboards' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
D.4.3 Testing the Dashboards
Before releasing dashboards and content to the user community, perform some tests.
-
Verify that users with appropriate permissions can correctly access it and view the intended content.
-
Verify that users without appropriate permissions cannot access the dashboard.
-
Verify that styles and skins are displayed as expected, and that other visual elements are as expected.
-
Correct any problems you find and test again, repeating this process until you are satisfied with the results.
D.4.4 Releasing Dashboards to the User Community
After testing is complete, notify the user community that the dashboard is available, ensuring that you provide the relevant network address.
D.5 Controlling Access to Saved Customization Options in Dashboards
This section provides an overview of saved customizations and information about administering saved customizations. It contains the following topics:
-
Section D.5.1, "Overview of Saved Customizations in Dashboards"
-
Section D.5.3, "Permission and Privilege Settings for Creating Saved Customizations"
-
Section D.5.4, "Example Usage Scenario for Saved Customization Administration"
D.5.1 Overview of Saved Customizations in Dashboards
Saved customizations allow users to save and view later dashboard pages in their current state with their most frequently used or favorite choices for items such as filters, prompts, column sorts, drills in analyses, and section expansion and collapse. By saving customizations, users need not make these choices manually each time that they access the dashboard page.
Users and groups with the appropriate permissions and dashboard access rights can perform the following activities:
-
Save various combinations of choices as saved customizations, for their personal use or use by others.
-
Specify a saved customization as the default customization for a dashboard page, for their personal use or use by others.
-
Switch between their saved customizations.
You can restrict this behavior in the following ways:
-
Users can view only the saved customizations that are assigned to them.
-
Users can save customizations for personal use only.
-
Users can save customizations for personal use and for use by others.
For information about end users and saved customizations with dashboards, see Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.
D.5.2 Administering Saved Customizations
This section describes the privileges and permissions that are required to administer saved customizations. It also describes the relevant portions of the Oracle BI Presentation Catalog that relate to storing and administering saved customizations.
D.5.2.1 Privileges for Saved Customizations
In Oracle BI Presentation Services Administration, the following privileges in the Dashboards area, along with permission settings for key dashboard elements, control whether users or groups can save or assign customizations:
-
Save Customizations
-
Assign Default Customizations
You can set neither privilege, one privilege, or both privileges for a user or group, depending on the level of access desired. For example, a user who has neither privilege can view only the saved customization that is assigned as his or her default customization.
D.5.2.2 Permissions for Saved Customizations
This section describes the permissions that are required for users to administer saved customizations of dashboard pages, and the relevant portions of the Oracle BI Presentation Catalog structure for setting permissions on shared and personal saved customizations.
D.5.2.2.1 Assigning Permissions to Dashboards
You set permissions for dashboards and pages, such as Full Control or No Access, in the Permission dialog in Oracle BI EE. You assign these permissions in the same manner as for other objects in the catalog.
D.5.2.2.2 Assigning Permissions for Customizations on a Dashboard Page
You set permissions for working with saved customizations on a particular dashboard page in the Dashboard Properties dialog, which is available in the Dashboard Builder. After selecting a page in the list in the dialog, click one of the following buttons:
-
Specify Who Can Save Shared Customizations displays the Permission dialog in which you specify who can save shared customizations for that dashboard page.
-
Specify Who Can Assign Default Customizations displays the Permission dialog in which you specify who can assign default customizations for that dashboard page.
Catalog objects and permissions scenarios are described in the following sections.
D.5.2.2.3 Catalog Folder Structure for Saved Customizations
In addition to the privileges that you set in Oracle BI Presentation Services Administration, the level of control that users and groups have over saved customizations depends on their access rights to key elements. For example, users and groups that can create and edit underlying dashboards, save dashboard view preferences as customizations, and assign customizations to other users as default customizations require Full Control permission to the key elements in shared storage, while users and groups that can view only their assigned default saved customizations need only View access to the key elements in shared storage.
Key elements in the catalog include the following folders:
-
Shared Storage Folders.
Shared storage folders for dashboards are typically located within the Dashboards sub-folder of a parent shared folder. Dashboards are identified by their assigned names. You can save a dashboard anywhere in the Oracle BI Presentation Catalog. If you save a dashboard within a subfolder called "Dashboards", then that dashboard's name is displayed in the list of dashboards that is displayed from the Dashboards link in the global header.
Permission settings control access to a specific dashboard for editing. Typically, if permissions are inherited down to the _selections and Dashboards sub-folders, then users who can edit dashboards can also save customizations and set defaults. Access to a specific dashboard folder controls whether a user or group can edit the dashboard.
The _selections folder contains a page identifier folder for each dashboard page. Shared saved customizations are located within this folder. Access to the page identifier folder controls whether a user or group can display, save, or edit customizations for that page.
The _defaults folder within a _selections folder contains assigned default customizations. Each group that has an assigned default is displayed here. Access to this folder controls whether a user or group can assign defaults.
-
Personal Storage Folders.
Within a user's personal folder, the _selections folder contains an individual user's saved customizations. Like the shared _selections folder, a personal _selections folder contains a page identifier folder for each dashboard page. The page identifier folder contains personal saved customizations and a _defaultlink file that specifies a user's preference for the personal defaulted customization.
A personal saved customization default overrides an assigned shared customization default.
Note:
If a dashboard page with saved customizations is deleted, then the saved customizations are also deleted from the catalog. If the underlying dashboard structure changes such that a saved customization is no longer valid when a user accesses it, then the default content is displayed on the dashboard.
D.5.3 Permission and Privilege Settings for Creating Saved Customizations
Table D-5 describes typical user roles and specific permission settings that can be granted to users for creating saved customizations. The folder names listed in the Permission and Privilege Settings column are described in the preceding section.
Table D-5 User Roles and Permission Settings for Saved Customizations
| User Role | Permission and Privilege Settings |
|---|---|
|
Power users such as IT users who must perform the following tasks:
|
In the Shared section of the catalog, requires Full Control permission to the following folders:
Typically, no additional privileges must be assigned. |
|
Technical users such as managers who must perform the following tasks:
Users cannot create or edit underlying dashboards, or assign view customizations to others as default customizations. |
In the Shared section of the catalog, requires View permission to the following folders:
In the Shared section of the catalog, requires Modify permission to the following folders:
Typically, no additional privileges must be assigned. |
|
Everyday users who must save customizations for personal use only. |
In Oracle BI Presentation Services Administration, requires the following privilege to be set:
In the dashboard page, requires that the following option is set:
In the catalog, no additional permission settings are typically required. |
|
Casual users who must view only their assigned default customization. |
In the Shared section of the catalog, the user needs View permission to the following folders:
In the catalog, no additional permission settings are typically required. |
D.5.4 Example Usage Scenario for Saved Customization Administration
Depending on the privileges set and the permissions granted, you can achieve various combinations of user and group rights for creating, assigning, and using saved customizations.
For example, suppose a group of power users cannot change dashboards in a production environment, but they are allowed to create saved customizations and assign them to other users as default customizations. The following permission settings for the group are required:
-
Open access to the dashboard, using the Catalog page.
-
Modify access to the _selections and _defaults subfolders within the dashboard folder in the Oracle BI Presentation Catalog, which you assign using the Dashboard Properties dialog in the Dashboard Builder. After selecting a page in the list in the dialog, click Specify Who Can Save Shared Customizations and Specify Who Can Assign Default Customizations.
D.6 Enabling Users to Act for Others
This section contains the following topics on enabling users to act for others:
D.6.1 Why Enable Users to Act for Others?
You can enable one user to act for another user in Oracle BI Presentation Services. When a user (called the proxy user) acts as another (called the target user), the proxy user can access the objects in the catalog for which the target user has permission.
Enabling a user to act for another is useful, for example, when a manager wants to delegate some of his work to one of his direct reports or when IT support staff wants to troubleshoot problems with another user's objects.
See Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for information on how users enable others to act for them.
D.6.2 What Are the Proxy Levels?
When you enable a user to be a proxy user, you also assign an authority level (called the proxy level). The proxy level determines the privileges and permissions granted to the proxy user when accessing the catalog objects of the target user. The following list describes the proxy levels:
-
Restricted — Permissions are read-only to the objects to which the target user has access. Privileges are determined by the proxy user's account (not the target user's account).
For example, suppose a proxy user has not been assigned the Access to Answers privilege, and the target user has. When the proxy user is acting as the target user, the target user cannot access Answers.
-
Full — Permissions and privileges are inherited from the target user's account.
For example, suppose a proxy user has not been assigned the Access to Answers privilege, and the target user has. When the proxy user is acting as the target user, the target user can access Answers.
When you have enabled a user to act as a proxy user, that user can display the Act As option in the global header of Presentation Services to select the target user to act as, provided the Act As Proxy privilege has been set.
Tip:
Before a proxy user can act as a target user, the target user must have signed into Presentation Services at least once and accessed a dashboard.Note:
If you are a user who can be impersonated by a proxy user, you can see the users with the permission to proxy (Act As) you. To see these users, log in to Oracle Business Intelligence, go to the My Account dialog box and display the extra tab called Delegate Users. This tab displays the users who can connect as you, and the permission they have when they connect as you (Restricted or Full).D.6.3 Process of Enabling Users to Act for Others
To enable users to act for others, perform the following tasks:
-
Section D.6.3.1, "Defining the Association Between Proxy Users and Target Users"
-
Section D.6.3.2, "Creating Session Variables for Proxy Functionality"
-
Section D.6.3.3, "Modifying the Configuration File Settings for Proxy Functionality"
-
Section D.6.3.4, "Creating a Custom Message Template for Proxy Functionality"
D.6.3.1 Defining the Association Between Proxy Users and Target Users
You define the association between proxy users and target users in the database by identifying, for each proxy user/target user association, the following:
-
ID of the proxy user
-
ID of the target user
-
Proxy level (either full or restricted)
For example, you might create a table called Proxies in the database that looks like this:
| proxyId | targetId | proxyLevel |
|---|---|---|
| Ronald | Eduardo | full |
| Timothy | Tracy | restricted |
| Pavel | Natalie | full |
| William | Sonal | restricted |
| Maria | Imran | restricted |
After you define the association between proxy users and target users, you must import the schema to the physical layer of the BI Server. For information on importing a schema, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
D.6.3.2 Creating Session Variables for Proxy Functionality
To authenticate proxy users, you must create the following two session variables along with their associated initialization blocks. For both variables, you must modify the sample SQL statement according to the schema of the database.
-
PROXY — Use this variable to store the name of the proxy user.
Use the initialization block named ProxyBlock and include code such as the following:
select targetId from Proxies where UPPER(targetid) = UPPER('VALUEOF(NQ_SESSION.RUNAS)') and UPPER(proxyid) = UPPER('VALUEOF(NQ_SESSION.RUNASORIGUSER)') -
PROXYLEVEL — Use this optional variable to store the proxy level, either Restricted or Full. If you do not create the PROXYLEVEL variable, then the Restricted level is assumed.
Use the initialization block named ProxyLevel and include code such as the following:
select proxyLevel from Proxies where UPPER(targetid) = UPPER('VALUEOF(NQ_SESSION.RUNAS)') and UPPER(proxyid) = UPPER('VALUEOF(NQ_SESSION.RUNASORIGUSER)')
For more information on creating session variables, see Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
D.6.3.3 Modifying the Configuration File Settings for Proxy Functionality
Use various elements in the instanceconfig.xml file to configure the proxy functionality.
Before you begin this procedure, ensure that you are familiar with the information in 'Using a Text Editor to Update Oracle Business Intelligence Configuration Settings' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
To manually configure for proxy functionality:
-
Open the instanceconfig.xml file for editing, as described in 'Where are Configuration Files Located' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
-
Locate the section in which you must add the elements that are described in the following list:
-
LogonParam: Serves as the parent element for the TemplateMessageName and MaxValues elements.
-
TemplateMessageName: Specifies the name of the custom message template in the Custom Messages folder that contains the SQL statement to perform tasks related to displaying proxy and target users. The default name is LogonParamSQLTemplate.
The name that you specify in the TemplateMessageName element must match the name that you specify in the WebMessage element in the custom message file. For more information, see Section D.6.3.4, "Creating a Custom Message Template for Proxy Functionality."
-
MaxValues: Specifies the maximum number of target users to be listed in the User box in the Act As dialog box. If the number of target users for a proxy user exceeds this value, then an edit box, where the proxy user can enter the ID of a target user, is shown rather than a list of target users. The default is 200.
-
-
Include the elements and their ancestor elements as appropriate, as shown in the following example:
<LogonParam> <TemplateMessageName>LogonParamSQLTemplate</TemplateMessageName> <MaxValues>100</MaxValues> </LogonParam> -
Save your changes and close the file.
-
Restart Oracle Business Intelligence.
D.6.3.4 Creating a Custom Message Template for Proxy Functionality
You must create a custom message template for the proxy functionality that contains the SQL statement to perform the following tasks:
-
Obtain the list of target users that a proxy user can act as. This list is displayed in the User box in the Act As dialog box.
-
Verify whether the proxy user can act as the target user.
-
Obtain the list of proxy users that can act as the target user. This list is displayed on the target user's My Account screen.
In the custom message template, you place the SQL statement to retrieve this information in the following XML elements:
| Element | Description |
|---|---|
| getValues | Specifies the SQL statement to return the list of target users and corresponding proxy levels.
The SQL statement must return either one or two columns, where the:
|
| verifyValue | Specifies the SQL statement to verify if the current user can act as the specified target user.
The SQL statement must return at least one row if the target user is valid or an empty table if the target user is invalid. |
| getDelegateUsers | Specifies the SQL statement to obtain the list of proxy users that can act as the current user and their corresponding proxy levels.
The SQL statement must return either one or two columns, where the:
|
You can create the custom message template in one of the following files:
-
The original custom message file in the directory
-
A separate XML file in the directory
To create the custom message template:
-
To create the custom message template in the original custom message file:
-
Make a backup of the original custom message file in a separate directory.
-
Make a development copy in a different directory and open it in a text or XML editor.
-
-
To create the custom message template in a separate XML file, create and open the file in the BI_DOMAIN/bidata/components/OBIPS/customMessages directory.
You must also configure a folder (for example, customMessages) as an application in WebLogic Server, to make Oracle BI Presentation Services aware of it. For more information, see, "Install applications and modules" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help in:
http://docs.oracle.com/cd/E23943_01/apirefs.1111/e13952/taskhelp/deployment/InstallApplicationsAndModules.html -
Start the custom message template by adding the WebMessage element's begin and end tags. For example:
<WebMessage name="LogonParamSQLTemplate"> </WebMessage>
Note:
The name that you specify in the WebMessage element must match the name that you specify in the TemplateMessageName element in the instanceconfig.xml file. For information, see Section D.6.3.3, "Modifying the Configuration File Settings for Proxy Functionality." -
After the </WebMessage> tag:
-
Add the <XML> and </XML> tags
-
Between the <XML> and </XML> tags, add the <logonParam name="RUNAS"> and </logonParam> tags.
-
Between the <logonParam name="RUNAS"> and </logonParam> tags, add each of the following tags along with its corresponding SQL statements:
-
<getValues> and </getValues>
-
<verifyValue> and </verifyValue>
-
<getDelegateUsers> and </getDelegateUsers>
-
The following entry is an example:
<?xml version="1.0" encoding="utf-8" ?> <WebMessageTables xmlns:sawm="com.example.analytics.web.messageSystem"> <WebMessageTable system="SecurityTemplates" table="Messages"> <WebMessage name="LogonParamSQLTemplate"> <XML> <logonParam name="RUNAS"> <getValues>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select targetId from SAMP_USERS_PROXIES where proxyId='@{USERID}'</getValues> <verifyValue>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select targetId from SAMP_USERS_PROXIES where proxyId='@{USERID}' and targetId='@{VALUE}'</verifyValue> <getDelegateUsers>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select proxyId, proxyLevel from SAMP_USERS_PROXIES where targetId='@{USERID}'</getDelegateUsers> </logonParam> </XML> </WebMessage> </WebMessageTable> </WebMessageTables>Note that you must modify the example SQL statement according to the schema of the database. In the example, the database and connection pool are both named Proxy, the proxyId is PROXYER, and the targetId is TARGET.
-
-
If you created the custom message template in the development copy of the original file, then replace the original file in the customMessages directory with the newly edited file.
-
Test the new file.
-
(Optional) If you created the custom message template in the development copy of the original file, then delete the backup and development copies.
-
Load the custom message template by either restarting the server or by clicking the Reload Files and Metadata link on the Presentation Services Administration screen. For information on the Administration page, see Section D.2.1, "Understanding the Administration Pages."
D.6.3.5 Assigning the Proxy Privilege
For each user whom you want to enable as a proxy user or for each application role or Catalog group whose members you want to enable as proxy users, you must grant the Act As Proxy privilege. For information on how to assign privileges, see Section D.2.3.2, "Setting Presentation Services Privileges for Application Roles."