14 Applying Data Access Security to Repository Objects

Learn about data access security available for Oracle BI repository objects.

Data access security controls the right to view and modify data. You can use the following data access security methods:

Row-level security.
Object permissions.
Query limits.

Tasks required to implement data access security include managing users, groups, and application roles, setting up custom LDAP servers, and managing custom authenticators, are covered in Security Guide for Oracle Business Intelligence Enterprise Edition.

Setting up SSL connections.
Defining application roles and functional groups.

You must create users and application roles before you can implement data access security.
Assigning users to application roles and functional groups.
Setting up LDAP servers.
Defining and managing custom authenticators.

In the Oracle BI Administration Tool use online mode to implement data access security. If you are using offline mode, see About Applying Data Access Security in Offline Mode.Oracle Business Intelligence usage tracking performs data access security auditing. See Managing Usage Tracking in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

This chapter contains the following topics:

About Data Access Security

After developing your metadata repository, you need to set up your data access security architecture.

Data access security accomplishes the following goals:

Protects business data from unauthorized access.
Protects your repository metadata such as measure definitions.
Prevents individual users from damaging overall system performance.

You can implement and enforce row-level data security in both the repository and in the database. Object permissions and query limits are set up in the repository and are enforced only by the Oracle BI Server.

If you choose to implement row-level security in the database, you should also implement object permissions and query limits in the repository. Database-level object restrictions on individual tables or columns, and other objects do not prevent users without access from seeing these repository objects. However, queries against those tables, columns, and other objects fail. You should set up object permissions in the repository to hide these objects from all clients.

Because a variety of clients can connect to the Oracle BI Server, you cannot implement or enforce data security in Oracle BI Presentation Services. You can use the Oracle BI Presentation Services set of security controls that enable setting up privileges to access functionality in the Oracle Business Intelligence user interface, as well as dashboards and analyses objects. If you only implement security controls in Oracle BI Server, the repository and database are exposed to SQL injection hacker attacks and other security vulnerabilities. You must provide object-level security in the repository to create rules that apply to all incoming clients.

Where to Find Information About Security Tasks

The table lists the location of security task information for Oracle Business Intelligence.

Task	Location
Setting up user authentication with the default authentication provider or an alternative authentication provider	Managing Security Using the Default Security Configuration in Security Guide for Oracle Business Intelligence Enterprise Edition
Creating and managing users and groups in the default authentication provider	Managing Users and Groups in the Embedded WebLogic LDAP Server in Security Guide for Oracle Business Intelligence Enterprise Edition
Creating application roles and managing policies in the default policy store	Managing the Policy Store in Securing Applications with Oracle Platform Security Services
Viewing and understanding the default Oracle Business Intelligence permissions used with application roles in the policy store	Default Permissions in Security Guide for Oracle Business Intelligence Enterprise Edition
Applying data access security in offline mode and setting up placeholder application roles	About Applying Data Access Security in Offline Mode
Setting up row-level data security	Setting Up Row-Level Security
Setting repository object permissions	Setting Up Object Permissions
Setting query limits (governors)	Setting Query Limits
Setting up single sign-on (SSO)	Enabling SSO Authentication in Security Guide for Oracle Business Intelligence Enterprise Edition
Enabling SSL communication	SSO Configuration in Oracle Business Intelligence in Security Guide for Oracle Business Intelligence Enterprise Edition
Managing custom authenticators	Authenticating by Using a Custom Authenticator Plug-In in Security Guide for Oracle Business Intelligence Enterprise Edition

Row-Level Security

Oracle Business Intelligence requires row-level security in the database.

You can configure your connection pools so that the Oracle BI Server passes the credentials for each user to the database.

The database uses the credentials to apply the database’s row-level security rules to user queries.

Row-level database security is different from database authentication. See About Authentication in the Security Guide for Oracle Business Intelligence Enterprise Edition. Row-level database security provides database authorization and applies access security to specific rows in the database.

The image shows how row-level security is enforced in the database for Oracle Business Intelligence queries. The security rules are applied to all incoming clients and cannot be breached, even when the Logical SQL query is modified. In this example, the results returned are different depending on the user that generated the query, even though the SQL query generated by the Oracle BI Server is the same. The returned results are based on rules created and enforced in the database.

Description of GUID-5527A825-70A7-48FA-96A2-A7EA2391C567-default.gif follows

Description of the illustration GUID-5527A825-70A7-48FA-96A2-A7EA2391C567-default.gif

You must define the users, permissions, and security policies in the database. Refer to your database documentation for more information.

When setting up row-level security consider the following configuration information:

Row-level security does not work when SSO is used, or for any cases that involve impersonation such as Delivers, because the password for the end user is not available to the Oracle BI Server.
A connection script can be used to achieve the same functionality for Oracle Database data sources.
For Essbase or Hyperion Financial Management data sources, the connection pool displays an additional option to implement SSO.

Setting Up Row-Level Security

You can choose to set up row-level security in the repository, or in the database.

Implementing row-level security in the repository provides many benefits, including the following:

All users share the same database connection pool for better performance
All users share cache for better performance
You can define and maintain security rules that apply across many federated data sources

Implementing row-level security in the database, in contrast, is good for situations where multiple applications share the same database. When you design and implement row-level security in the database, you should also define and apply object permissions in the repository.

Although it is possible to set up row-level security in both the repository and in the database, you typically do not enforce row-level security in both places unless you have a particular need to do so.

This section contains the following topics:

Data Filters

Use the Oracle BI Administration Tool to define data filters on repository objects for specific application roles.

You typically do not set up data filters if you have implemented row-level security in the database, because in this case, your row-level security policies are being enforced by the database rather than the Oracle BI Server.

You can set data filters for objects in the Business Model and Mapping layer and the Presentation layer. Applying a filter on a logical object impacts all Presentation layer objects that use the object. If you set a filter on a Presentation layer object, it is applied to the object along with any other filters that are set on the underlying logical objects.

The image shows how data filter rules are enforced in the Oracle BI Server. The security rules are applied to all incoming clients and cannot be breached, even when the Logical SQL query is modified.

In this example, a filter has been applied to an application role. When Anne Green, who is a member of that role, sends a request, the return results are limited based on the filter. Because no filters have been applied to the application roles for the Administrator user, all results are returned. The Oracle BI Server-generated SQL takes into account any data filters that have been defined.

Description of GUID-5BF2A238-B5D9-4C0A-9228-EE2702956AA1-default.gif follows

Description of the illustration GUID-5BF2A238-B5D9-4C0A-9228-EE2702956AA1-default.gif

Setting Up Data Filters in the Repository

Use these steps to assign data filters to enforce row-level security rules in the repository.

You should always set up data filters for a specific application roles rather than for individual users.

To create filters, you first select objects from subject areas on which you want to apply the filters. Then, you provide the filter expression information for the individual objects. For example, you might want to define a filter like "Sample Sales"."D2 Market"."M00 Mkt Key" > 5 to restrict results based on a range of values for another column in the table.

If you are in offline mode, and application roles do not appear in the Identity Manager, see About Applying Data Access Security in Offline Mode.

You can also use repository and session variables in filter definitions. Use Expression Builder to include these variables to ensure the correct syntax.

When a repository object such as a logical fact table is accessed by multiple application roles with different levels of access, create functional groups to prevent application roles from viewing data restricted from view by that specific application role. For example, you want your regional sales associates to see the revenue for a quarter in their assigned region, but you don’t want your regional sales associate to see to total segment sales for all of the regions, to avoid exposing sensitive information, you create functional groups with different levels of access as appropriate for the specific application role to the filter. See Specifying a Functional Group for an Application Role.

In the Oracle BI Administration Tool, open your repository.
Select Manage, then select Identity.
In the Identity Manager dialog, double-click an application role.
In the Application Role dialog, click Permissions.
In the Application Role Permissions dialog, click the Data Filters tab.
From the Subject Area list, select a repository object to use in the filter.
Do one of the following:
- Click Add button to browse to locate the object to use, and then click Select.
- Double-click the Name field in an empty row, then browse to locate the object, and double-click to select the object.
Select the data filter to define, click the Expression Builder icon.
In the Expression Builder, define the condition using the repository objects and operators.
(Optional) From the Status list.
Click OK, then click OK again to return to the Identity Manager.

Specifying a Functional Group for an Application Role

Use these steps to specify a functional group for application roles with different data access filters on the same repository object, usually a logical fact table.

When there are no functional groups defined, all the security filters applied to a given table, regardless of the associated role, and are combined using the OR operator. Using the OR operator works in most cases because a user can view a union of all the rows selected by the security filters. For example, consider the following filters:

Role A is assigned the filter, Product = 'Coke'

Role B is assigned the filter, Product = 'Pepsi'

If a user is given Role A and Role B, then the user can view data for both the Coke and Pepsi products.

When the two security filters from the same table are combined in the query, the filter conditions are combined using the OR operator, this is appropriate for most security filters defined on dimension tables, for example:

Product = 'Coke' OR Product = 'Pepsi'

Using functional groups are necessary is when securing a single fact table, using data filters from different dimensions.

In this example, a fact table is secured using the following filters:

Role A is assigned the filter, Product = 'Coke'

Role B is assigned the filter, Product = 'Pepsi'

Role C is assigned the filter, Region = 'Southwest'

If you do not use functional groups, a user with roles A, B, and C would have all three filter conditions combined in the query using the OR operator, for example:

(Product = 'Coke' OR Product = 'Pepsi' OR Region = 'Southwest')

Combining the results of Role A, B, and C does not make sense because Product and Region are independent dimensions. Combining data filters from different dimensions using OR operator provides the user access to more data values than the user should view.

In this example, the user can see data for all products within the Southwest region as well as data for all regions within the Pepsi and Coke products.

To get the expected behavior, that is allowing the user to see data only for the Pepsi and Coke products within the Southwest region, you need to change the filter to combine the product filters with the region filter using the AND operator, for example:

(Product = 'Coke' OR Product = 'Pepsi') AND (Region = 'Southwest')

To achieve this using functional groups, assign the security filters to functional groups as follows:

Role A is assigned the filter, Product = 'Coke' with functional group "Product"

Role B is assigned the filter, Product = 'Pepsi' with functional group "Product"

Role C is assigned the filter, Region = 'Southwest' with functional group "Region"

All the filters in the same functional group are combined using the OR operator and all sets of filters in different functional groups are combined using the AND operator. By choosing the functional groups associated with each security filter, you can control how the filters are combined using the OR and AND operators.

To create a data filter, see Setting Up Data Filters in the Repository.

In the Oracle BI Administration Tool, from Manage, select Identity.
In the Identity Manager, double-click an application role.
In Application Role, click Permissions.
In Application Role Permissions, click the Data Filters tab.
In the Data Filter tab, select the filter to assign to a functional group.
In the Functional Group column, select an existing group, or typing the name of a new group to use.
Click OK.

Setting Up Row-Level Security in the Database

You must implement row-level security in the database to set up Oracle Business Intelligence. You can configure your connection pools so that the Oracle BI Server passes the credentials for each user to the database.

Open your repository in the Administration Tool.
Double-click the connection pool associated with the database for which you want to set up database-level security.
In the General tab of the Connection Pool dialog, select Shared logon, and then enter :USER and :PASSWORD in the User name and Password fields.

The :USER and :PASSWORD syntax automatically passes the value of user credentials upon login to the database. The :USER and :PASSWORD syntax does not refer to session variables.

Note:

You can use the database session context to pass end user identity to the database. Use a connection pool script to set up session context. This approach does not rely on database authentication.
Click OK in the Connection Pool dialog.
Double-click the database object for which you want to set up database-level security.
In the Database dialog, select Virtual Private Database. Selecting this option ensures that the Oracle BI Server protects cache entries for each user.
Click OK in the Database dialog.

After you have set up row-level security in the database, you must set up object permissions in the repository for Presentation layer or other objects. You can also set query limits (governors). See Setting Up Object Permissions and Setting Query Limits.

Object Permissions

You can set up object permissions in your repository to control access to Presentation layer and Business Model and Mapping layer objects

You set object permissions using the Oracle BI Administration Tool.

To set up object permissions:

Set the data access for specific application roles.
Specify functional groups when multiple application roles have different levels of access to the same object.
Select individual objects in the Presentation layer.

Set up object permissions for application roles when you want to define data access permissions for a set of objects that are common to users assigned the specific application role. You should set up object permissions for specific application roles rather than for individual users to simplify data access management.

The following image shows how object permissions can restrict users from viewing specific repository object. Security rules are applied to all incoming client queries, and cannot be breached, even when the Logical SQL query is modified. In this example, the Administrator application role has been granted access to the Booked Amount column allowing the Administrator to view the returned results. The user, Anne Green, who is not a member of an application role with access to the Booked Amount column, cannot see the column in the Subject Area pane of Oracle BI Answers. Even if the query is modified, results are not returned for the Booked Amount column because of the application role-based object permissions have been set.

Description of GUID-8FE8FFB0-336E-42BD-98E1-8F415B5CC97E-default.gif follows

Description of the illustration GUID-8FE8FFB0-336E-42BD-98E1-8F415B5CC97E-default.gif

If an application role has permissions on an object from multiple sources, for example, explicitly and through one or more additional application roles, the permissions are applied based on the order of precedence.
If you explicitly deny access to an object that has child objects, users who are members of the individual application role are denied access to the child objects. For example, if you explicitly deny access to a particular logical table, you are implicitly denying access to all of the logical columns associated with that table.
Object permissions do not apply to repository and session variables, so values in these variables are not secure. Anyone who knows or can guess the name of the variable can use it in an expression in Oracle BI Answers or in a Logical SQL query. Do not put sensitive data like passwords in session or repository variables.
You can control the level of privilege is granted by default to the AuthenticatedUser application role. The AuthenticatedUser is the default application role associated with new repository objects.

The AuthenticatedUser application role means any authenticated user. The AuthenticatedUser application role is internal to the Oracle BI Repository. The AuthenticatedUser application role appears in the Permissions dialog for connection pools and Presentation layer objects. The AuthenticatedUser does not appear in the list of application roles in the Identity Manager.

Update the DEFAULT_PRIVILEGES parameter in the NQSConfig.INI file. See Security Section Parameters in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Setting Up Object Permissions

Use these steps to set up object permissions for individual application roles in your repository to control access to Presentation layer and Business Model and Mapping layer objects.

Application roles are not displayed if you are using offline mode unless you have first modified them in online mode. See About Applying Data Access Security in Offline Mode.

Open your repository in the Administration Tool.
Select Manage, then select Identity.
In the Identity Manager dialog, in the tree pane, select BI Repository.
In the right pane, select the Application Roles tab, then double-click the application role for which you want to set object permissions.
In the Application Role dialog, click Permissions.
In the User/Application Role Permissions dialog, in the Object Permissions tab, do one of the following to select an object:
- Click the Add button, locate the object, and then click Select.
- Click the Name field in an empty row, locate the object, and then click Select
Assign the appropriate permission for each object. You can choose one of the following options:
- Read: Only allows read access to this object.
- Read/Write: Provides both read and write access to this object.
- No Access: Explicitly denies all access to this object.
Click OK, then click OK again to return to the Identity Manager.

About Permission Inheritance for Users and Application Roles

Users can have explicitly granted permissions. They can also have permissions granted through membership in application roles, that in turn can have permissions granted through membership in other application roles.

Permissions granted explicitly to a user have precedence over permissions granted through application roles, and permissions granted explicitly to the application role take precedence over any permissions granted through other application roles.

If there are multiple application roles acting on a user or application role at the same level with conflicting security attributes, then the user or application role is granted the least restrictive security attribute. Oracle currently requires that the application role with access to an object also have access to the object's container. For example, if ApplicationRole 1 has permission to access Column A, which is part of Table B, then ApplicationRole1 must also have permission to access Table B. Any explicit permissions acting on a user take precedence over any permissions on the same objects granted to that user through application roles.

In previous releases, the application role did not require access to an object's container, as described above. To revert to this behavior, go to the Oracle BI Server machine and create environment variable OBIS_SECURITY_10g_COMPATIBLE and set it to 1.

Filter definitions, however, are always inherited. For example, if User1 is a member of Role1 and Role2, and Role1 includes a filter definition but Role2 does not, the user inherits the filter definition defined in Role1.

You should always define object permissions for application roles rather than for individual users.

Description of GUID-495F4979-86CB-481F-A061-2462D3B1EF60-default.gif follows

Description of the illustration GUID-495F4979-86CB-481F-A061-2462D3B1EF60-default.gif

Description of GUID-7822C7C1-8DCD-46FE-8990-42C88D31C92F-default.gif follows

Description of the illustration GUID-7822C7C1-8DCD-46FE-8990-42C88D31C92F-default.gif

These are the resulting permissions:

User1 is a direct member of Role1 and Role2, and is an indirect member of Role3, Role4, and Role5.
Because Role5 is at a lower level of precedence than Role2, its denial of access to TableA is overridden by the READ permission granted through Role2. The result is that Role2 provides READ permission on TableA.
The resultant permissions from Role1 are NO ACCESS for TableA, READ for TableB, and READ for TableC.
Because Role1 and Role2 have the same level of precedence and because the permissions in each cancel the other out (Role1 denies access to TableA, Role2 allows access to TableA), the less restrictive level is inherited by User1. In other words, User1 has READ access to TableA.
The total permissions granted to User1 are READ access for TableA, TableB, and TableC.

Permission Inheritance 1

You might have a user (User1) who is explicitly granted permission to read a given table (TableA). Suppose also that User1 is a member of Role1, and Role1 explicitly denies access to TableA. The resultant permission for User1 is to read TableA.

Because permissions granted directly to the user take precedence over those granted through application roles, User1 has the permission to read TableA.

Overview of User and Application Role Commands

Learn about commands that you can use with the repository and the Oracle BI Presentation Catalog.

You can use the following commands to update application roles and users stored in the repository and the Oracle BI Presentation Catalog:

Note:

The remaining upload and update commands, for example, Upload Repository Command and Update Repository Variables Command, only update the repository.

The application roles and users update commands use two plugins, the RPD plugin, which updates the application roles and users in the repository, and the WEBCAT plugin, which updates application roles and the users in the Oracle BI Presentation Catalog.

These plugins function separately, and therefore the failure of one does not impact the other. In the event of a partial failure, or one of the two plugins failing, Oracle recommends that you address the root cause of the failure and then re-execute the command as you initially ran it. Reapplying the successful plugin has no impact on the results, but re-executing the command reruns the failed plugin.

By default, the application roles and users update commands run the two plugins, and the order in which they are run is RPD and then WEBCAT. However, the commands include the -L option which allows you to specify an individual plugin or to reverse the default order in which the plugins are run. Run the commands in the default order. You might need to run only one plugin or reverse the order of the plugins.

Rename Application Role Command

Use the renameapproles command to upload a JSON file containing information about the application roles that you want to rename for a specific server instance.

You execute the renameapproles command through a launcher script, datamodel.sh on UNIX and datamodel.cmd on Windows.

If the domain is installed in default folder then the location of the launcher script looks like the following:

Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.sh or datamodel.cmd on Windows

If the client install doesn't have domain names, the launcher script location is as follows:

Oracle_Home\bi\bitools\bin\datamodel.cmd

See What You Need to Know Before Using the Command and Overview of User and Application Role Commands.

Syntax

The renameapproles command takes the following parameters:

renameapproles -T inputfile.json[-L plugin list] -SI service instance -U cred username[-P cred password] [-S hostname] [-N <port number] [-SSL] [-H]

Where

T specifies the name of the JSON input file containing the application role name changes for the server instance.

SI specifies the name of the service instance.

L specifies a single plugin to run or to reverse the default plugin execution order. The plugins determine where the system applies the updates: to the repository, the Oracle BI Presentation Catalog, or both. See Overview of User and Application Role Commands.

Note:

The following options are for L:

RPD: Specify this option to rename application roles in the repository, only.
WEBCAT: Specify this option to rename application roles in the Oracle BI Presentation Catalog. For example, you must use the -L WEBCAT option when renaming application roles in the Oracle BI Presentation Catalog.
WEBCAT,RPD: Specify this option to reverse the default plugin run order.

The default plugin run order is repository (RPD) and then Oracle BI Presentation Catalog (WEBCAT).
Omit this option to execute the plugins in their default order, which is repository (RPD) and then Oracle BI Presentation Catalog .

U specifies a valid user's name to be used for Oracle BI EE authentication.

P specifies the password corresponding to the user's name that you specified for U. If you do not supply the password, you are prompted for the password when the command is run. Oracle recommends that you include a password in the command only if you are using automated scripting to run the command.

S specifies the Oracle BI EE host name. Only include this option when you are running the command from a client installation.

N specifies the Oracle BI EE port number. Only include this option when you are running the command from a client installation.

SSL specifies to use SSL to connect to the Oracle WebLogic Server to run the command. Only include this option when you are running the command from a client installation.

H displays the usage information and exits the command. Use -H or run .sh without any parameters to display the help content.

Example

datamodel.sh renameapproles -T approlenames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL

Creating a JSON Rename Application Role Input File

Use the following syntax to create the JSON rename application role input file.

{
    "Title":"Target Application Roles",
    "App-Roles":[
          { "oldname":"<current_approle1>", "newname":"<new_approle1>" },
          { "oldname":"<current_approle2>", "newname":"<new_approle2>" },
          { "oldname":"<current_approle3>", "newname":"<new_approle3>" }
   ]
}

Delete Application Role Command

Use the deleteapproles command to upload a JSON file containing a list of application roles that you want to delete from a specific server instance.

You execute the utility through a launcher script, datamodel.sh on UNIX and datamodel.cmd on Windows.

If the domain is installed in default folder then the location of the launcher script looks like the following:

Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.sh or datamodel.cmd on Windows

If the client install doesn't have domain names, the launcher script location is as follows:

Oracle_Home\bi\bitools\bin\datamodel.cmd

See What You Need to Know Before Using the Command and Overview of User and Application Role Commands.

Syntax

The deleteapproles command takes the following parameters:

deleteapproles -T inputfile.json[-L plugin list] -SI service_instance -U cred_username[-P cred_password] [-S hostname] [-N port_number] [-SSL} [-H]

Where

T specifies the name of the JSON input file containing the application roles to be deleted from the server instance.

L specifies a single plugin to run or to reverse the default plugin execution order. The plugins determine where the system applies the updates: to the repository, the Oracle BI Presentation Catalog, or both. For RPD and WEBCAT plugin usage information, see Overview of User and Application Role Commands.

The following options are available for L:

RPD: Specify this option to delete application roles in the repository, only.
WEBCAT: Specify this option to delete application roles in the Oracle BI Presentation Catalog, only. You must use the -L WEBCAT option when deleting application roles.
WEBCAT,RPD: Specify this option to reverse the default plugin run order. The default plugin run order is repository (RPD) and then Oracle BI Presentation Catalog (WEBCAT).
Omit this option to execute the plugins in their default order.

SI specifies the name of the service instance.

U specifies a valid user's name to be used for Oracle BI EE authentication.

P specifies the password corresponding to the user's name that you specified for U. If you do not supply the password, then you are prompted for the password when the command is run. Oracle recommends that you include a password in the command only if you are using automated scripting to run the command.

S specifies the Oracle BI EE host name. Only include this option when you are running the command from a client installation.

N specifies the Oracle BI EE port number. Only include this option when you are running the command from a client installation.

SSL specifies to use SSL to connect to the Oracle WebLogic Server to run the command. Only include this option when you are running the command from a client installation.

H displays the usage information and exits the command. Use -H or run .sh without any parameters to display the help content.

Example

datamodel.sh deleteapproles -T approlenames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL

Creating a JSON Delete Application Role Input File

Use the following syntax to create the JSON delete application role input file.

{
    "Title":"Target Application Roles",
    "App-Roles":[
         { "name":"<approle1>" },
         { "name":"<approle2>" },
         { "name":"<approle3>" }
   ]
}

Rename Users Command

Use the renameusers command to upload a JSON file containing a list of information about the users that you want to rename for a specific server instance.

You execute the utility through a launcher script, datamodel.sh on UNIX and datamodel.cmd on Windows.

If the domain is installed in default folder then the location of the launcher script looks like the following:

Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.sh or datamodel.cmd on Windows

If the client install doesn't have domain names, the launcher script location is as follows:

Oracle_Home\bi\bitools\bin\datamodel.cmd

See What You Need to Know Before Using the Command.

See Overview of User and Application Role Commands.

Syntax

The renameusers command takes the following parameters:

renameusers -T usernames.json[-L plugin list] -SI service instance -U cred username[-P cred password] [-S hostname] [-N port number] [-SSL] [-H]

Where

T specifies the name of the JSON input file containing the user name changes for the server instance.

Note:

The following options are for L:

RPD: Specify this option to rename users in the repository, only.
WEBCAT: Specify this option to rename users in the Oracle BI Presentation Catalog. For example, you must use the -L WEBCAT option when renaming users in the Oracle BI Presentation Catalog.
WEBCAT,RPD: Specify this option to reverse the default plugin run order. The default plugin run order is repository (RPD) and then Oracle BI Presentation Catalog (WEBCAT).
Omit this option to execute the plugins in their default order.

SI specifies the name of the service instance.

U specifies a valid user's name to be used for Oracle BI EE authentication.

P specifies the password corresponding to the user's name that you specified for U. If you do not supply the password, then you are prompted for the password when the command is run. For security purposes, Oracle recommends that you include a password in the command only if you are using automated scripting to run the command.

S specifies the Oracle BI EE host name. Only include this option when you are running the command from a client installation.

N specifies the Oracle BI EE port number. Only include this option when you are running the command from a client installation.

SSL specifies to use SSL to connect to the Oracle WebLogic Server to run the command. Only include this option when you are running the command from a client installation.

H displays the usage information and exits the command. Use -H or run .sh without any parameters to display the help content.

Example

datamodel.sh renameusers -T usernames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL

Creating a JSON Rename Users Input File

Use the following syntax to create the JSON rename users input file.

{
    "Title":"Target Users",
    "Users":[
          { "oldname":"<current_user1>", "newname":"<new_user1>" },
          { "oldname":"<current_user2>", "newname":"<new_user2>" },
          { "oldname":"<current_user3>", "newname":"<new_user3>" }
    ]
}

Delete Users Command

Use the deleteusers command to upload a JSON file containing a list of users that you want to delete from a specific server instance.

You execute the utility through a launcher script, datamodel.sh on UNIX and datamodel.cmd on Windows.

If the domain is installed in default folder then the location of the launcher script looks like the following:

Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.sh or datamodel.cmd on Windows

If the client install doesn't have domain names, the launcher script location is as follows:

Oracle_Home\bi\bitools\bin\datamodel.cmd

See What You Need to Know Before Using the Command and Overview of User and Application Role Commands

Syntax

The deleteusers command takes the following parameters:

deleteusers -T usernames.json [-L plugin list] -SI service_instance-U cred_username[-P cred_password] [-S hostname] [-N port_number] [-SSL] [-H]

Where

T specifies the name of the JSON input file containing the users to be deleted from the server instance. See the syntax in Creating a JSON Delete Users Input File for information about the correct syntax for the application role input file.

The following options are for L:

RPD: Specify this option to delete users in the repository, only.
WEBCAT: Specify this option to delete users in the Oracle BI Presentation Catalog. For example, you must use the-L WEBCAT option when deleting users from the Oracle BI Presentation Catalog.
WEBCAT,RPD: Specify this option to reverse the default plugin run order. The default plugin run order is repository (RPD) and then Oracle BI Presentation Catalog (WEBCAT).
Omit this option to execute the plugins in their default order, which is repository (RPD) then Oracle BI Presentation Catalog (WEBCAT).

SI specifies the name of the service instance.

U specifies a valid user's name to be used for Oracle BI EE authentication.

S specifies the Oracle BI EE host name. Only include this option when you are running the command from a client installation.

N specifies the Oracle BI EE port number. Only include this option when you are running the command from a client installation.

SSL specifies to use SSL to connect to the Oracle WebLogic Server to run the command. Only include this option when you are running the command from a client installation.

H displays the usage information and exits the command. Use -H or run .sh without any parameters to display the help content.

Example

data-model-cmd.sh deleteusers -T usernames.json -SI bi -U weblogic -P password -S server1.us.example.com -N 777 -SSL

Creating a JSON Delete Users Input File

Use the following syntax to create the JSON delete users input file.

{
    "Title":"Target Users",
    "Users":[
         { "name":"<user1>" },
         { "name":"<user2>" },
         { "name":"<user3>" }
    ]
}

Setting Query Limits

You can manage the query environment by setting query limits (governors) in the repository for particular application roles.

You can limit queries by the number of rows received, by maximum run time, and by restricting to particular time periods. You can also allow or disallow direct database requests or the Populate privilege.

You should always set query limits for particular application roles rather than for individual users.

This section contains the following topics:

Accessing the Query Limits Functionality in the Administration Tool

Learn how to access the Query Limits tab of the User/Application Role Permissions dialog.

Note:

If you are in offline mode, no application roles appear in the list unless you have first modified them in online mode, see About Applying Data Access Security in Offline Mode.

Open your repository in the Administration Tool to access the query limits functionality for an application role.
Select Manage, then select Identity.
In the Identity Manager dialog, in the tree pane, select BI Repository.
In the right pane, select the Application Roles tab, then double-click the application role for which you want to set query limits.
In the Application Role dialog, click Permissions.
In the User/Application Role Permissions dialog, click the Query Limits tab.

Limiting Queries By the Number of Rows Received

You can control runaway queries by limiting queries to a specific number of rows.

Any query limits you set should exceed the Presentation Server settings for Maximum Number of Rows Processed when Rendering a Table View and Maximum Number of Rows to Download by at least 500 to avoid error messages. If you choose to impose data source rows limits on certain users or Application Roles using the repository Max Rows query limits setting, then those users may receive Max Row Limit Exceeded messages.

See Using Fusion Middleware Control to Set Configuration Options for Data in Tables and Pivot Tables and Using Fusion Middleware Control to Set the Maximum Number of Rows Processed to Render a Table in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

The options for Status Max Rows are:

Enable: This limits the number of rows to the value specified. If the number of rows exceeds the Max Rows value, the query is terminated.
Disable: Disables any limits set in the Max Rows field.
Warn: Does not enforce limits, but logs queries that exceed the set limit in the Query log.
Ignore: Limits are inherited from the parent application role. If there is no row limit to inherit, no limit is enforced.

Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.

In the Max Rows column, type the maximum number of rows for users to retrieve from each source database object.
In the Status Max Rows field, select an option for each database.
Click OK, then click OK again to return to the Identity Manager.

Limiting Queries By Maximum Run Time and Restricting to Particular Time Periods

You can forbid queries during certain time periods, or you can specify the maximum time a query can run on a database.

If you do not select a particular time period, access rights remain unchanged. If you allow or disallow access explicitly in one or more application roles, users are granted the least restrictive access for the defined time periods. For example, if a user is a member of an application role that is explicitly allowed access all day on Mondays, but that user also belongs to another application role that is disallowed access during all hours of every day, then the user has access on Mondays only.

Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.
To specify the maximum time a query can run on a database, in the Max Time (Minutes) column, enter the maximum number of minutes you want queries to run on each database object. Then, in the Status Max Time field, select one of the following options for each database:
- Enable: This limits the time to the value specified.
- Disable: Disables any limits set in the Max Time field.
- Warn: Does not enforce limits, but logs queries that exceed the set time limit in the Query log.
- Ignore: Limits are inherited from the parent application role. If there is no time limit to inherit, no limit is enforced.
To restrict access to a database during particular time periods, in the Restrict column, click the Ellipsis button. Then, in the Restrictions dialog, perform the following steps:
1. To select a time period, click the start time and drag to the end time.
2. To explicitly grant access, click Allow.
3. To explicitly deny access, click Disallow.
4. Click OK.
Click OK, then click OK again to return to the Identity Manager.

Allowing or Disallowing Direct Database Requests

Use this task to allow or disallow the ability to execute direct database requests for a particular application role.

For the selected role, this privilege overrides the Allow direct database requests by default property for the database object in the Physical layer.

The options for the Execute Direct Database Requests field are:

Allow
Explicitly grants the ability to execute direct database requests for this database.
Disallow
Explicitly denies the ability to execute direct database requests for this database.
Ignore
Limits are inherited from the parent application role. If there is no limit to inherit, then direct database requests are allowed or disallowed based on the Allow direct database requests by default property for the database object.

Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.

In the Query Limits tab for each database object, in the Execute Direct Database Requests field, select an option.
Click OK, then click OK again to return to the Identity Manager.

Allowing or Disallowing the Populate Privilege

When a criteria block is cached, the Populate stored procedure writes the Cache/Saved Result Set value to the database.

You can grant or deny this Populate privilege to particular application roles.

For the selected application role, this privilege overrides the Allow populate queries by default property for the database object in the Physical layer.

Any Oracle Marketing Segmentation user who writes a cache entry or saves a result set must be a member of an application role that has been assigned the POPULATE privilege for the target database.

The options for the Populate Privilege field are:

Allow
Explicitly grants the Populate privilege for this database. For all Marketing data warehouses, select Allow.
Disallow
Explicitly denies the Populate privilege for this database.
Ignore
Limits are inherited from the parent application role. If there is no limit to inherit, then the Populate privilege is allowed or disallowed based on the Allow populate queries by default property for the database object.

Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.

For each database object, in the Populate Privilege field, select an option.
Click OK, and then click OK again to return to the Identity Manager.

About Applying Data Access Security in Offline Mode

You should perform data access security tasks in the Oracle BI Administration Tool in online mode.

The Administration Tool does not store users in the repository, and you cannot create a query that returns repository users.

When you open the repository In online mode, you can retrieve the latest list of application roles from the policy store by selecting Action, then selecting Synchronize Application Roles in the Identity Manager.

Setting Up Placeholder Application Roles for Offline Repository Development

Application roles are created and managed in the policy store using the Oracle WebLogic Administration Console and Fusion Middleware Control.

These application roles are displayed in the Administration Tool in online mode so that you can use them to set data filters, object permissions, and query limits for particular roles. The application roles in the policy store are retrieved by the Oracle BI Server when it starts.

In some cases, you may want to proceed with setting up data access security in your repository for application roles that have not yet been defined in the policy store. You can do this by creating placeholder application roles in the Administration Tool, then proceeding with setting up data access security in the repository.

If you create placeholder application roles in the Administration Tool, you must eventually add them to the policy store. Run a consistency check in online mode to identify application roles that have been defined in the Administration Tool, but that have not yet been added to the policy store. Be sure to use the same name in the policy store that you used for the placeholder role in the Administration Tool.

Note:

Use caution when defining and using placeholder roles. If you make changes to a role in offline mode that also exists in the policy store, the changes are overwritten the next time you connect to the Oracle BI Server.

Open your repository in the Administration Tool.
Select Manage, then select Identity.
In the Identity Manager dialog, select Action, select New, and then select Application Role.
In the Application Role dialog, provide the following information:
- Name: Provide a name for the role.
- Display Name: Enter the display name for the role.
- Description: (Optional) provide a description of this application role.
- Members: Use the Add and Remove buttons to add or remove users and other application roles as appropriate.
- Permissions: Set object permissions, data filters, and query limits for this application role as appropriate. Refer to the other sections in this chapter for detailed information.
Click OK to return to the Identity Manager.

Open your repository in online mode in the Administration Tool.
Select File, then select Check Global Consistency.

Record any entries related to application roles, then add the appropriate roles to the policy store as appropriate. See Using Tools to Configure Security in Oracle Business Intelligence in the Security Guide for Oracle Business Intelligence Enterprise Edition for information about adding application roles to the policy store.
(Optional) Select individual rows, and click Copy to copy the entries to a text file.

You can check an individual application role by right-clicking the application role in the Identity Manager dialog and then selecting Check Consistency.