Siebel Analytics Installation and Configuration Guide > Integrated Security in Siebel Operational Applications and Siebel Analytics > Integrated Security for Responsibilities and Groups in Siebel Analytics Applications >

Implementing Data-Level Security in the Siebel Analytics Repository

NOTE:  Data-level security in Siebel Analytics applications is based on the position- and organization-based security model of the Siebel operational applications. For more information, see Security Guide for Siebel eBusiness Applications.

This section describes the configuration of data from the Siebel Data Warehouse, and refers only to the Data Warehouse tables. The setup for the Siebel transactional database (OLTP) data is similar, although the physical schema joins are different.

Data-level security in the Analytics repository is implemented in three major steps:

  1. Set up initialization blocks that obtain specific security-related information, such as the user's primary position ID, when a user logs in.
  2. Set up the joins to the appropriate security tables in the metadata physical and logical layers.
  3. Set up the filters for each security group on each logical table that needs to be secured.

For more information about security groups and filters as well as on how to set up joins in the repository, see Siebel Analytics Server Administration Guide.

In the Siebel Analytics repository, the initialization blocks have already been set up for obtaining a given user's primary position, primary organization, and the owner ID. There are three initialization blocks:

There are also preconfigured groups that have been set up with filters on several logical dimensions. The two groups that have filters on them are Primary Position-based Security and Primary Org-based Security. Table 18 shows the logical tables and the kind of security applied on those tables.

An example of how to configure the Opportunity Dimension is given as follows.


W_PARTY_LOGIN is the security table that stores recursive information about a given user's login and the parties (positions and organizations, employees) that report to the user through a hierarchical reporting mechanism. There is an alias setup on W_PARTY_LOGIN for each join with a dimension.

You can add security to a new dimension—for example, W_AGREE_D (Agreements).

To configure the physical table join between W_OPTY_D and W_PARTY_LOGIN

  1. Create an alias on W_PARTY_LOGIN specifically to join to W_AGREE_D.
  2. Configure the join in the physical layer.
  3. Configure a logical table join by adding the appropriate tables in the business layer.

    NOTE:  The columns VIS_PR_POS_ID and VIS_PR_BU_ID in the dimensional tables contain the record's primary owning position and owning organization.

  4. Configure the filter on the logical tables that restrict the data.
    1. To set up a filter, right-click on the group and choose Properties.
    2. In the Properties dialog box, click on the Permissions box and select the Filter tab, as shown in the following screen:
      Click for full size image
    3. To add a new filter, click on the ellipsis box and find the business model layer table that needs to be secured.
    4. Configure the WHERE clause on the table so that the data is filtered.

Organization-based security has been implemented using the row-wise initialized variable ORGANIZATION. This implementation is slightly different from that of the position-based security, because the number of organizations is usually limited, compared to the number of positions in a given environment. Therefore, using the row-wise initialized variable ORGANIZATION to filter data using a WHERE IN clause is efficient. However, joining the dimension with the W_PARTY_LOGIN is more efficient, because the number of positions used for filtering the data can be large.

 Siebel Analytics Installation and Configuration Guide, Version 7.7, Rev. A 
 Published: 11 March 2004