Siebel Analytics Installation and Configuration Guide > Applications User Authentication and Security Setup > Integrated Security for Responsibilities and Groups >

Implementing Data-Level Security in the Repository

NOTE:  Data-level security in Siebel Analytics applications is based on the position- and organization-based security model of the Siebel eBusiness applications. Refer to 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 & 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 setup joins in the repository, see Siebel Analytics Web 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 13 shows the logical tables and the kind of security applied on those tables.

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

"W_PARTY_LOGIN (W_OPTY_D)".PARTY_ID = W_OPTY_D.VIS_PR_POS_ID

W_PARTY_LOGIN is the security table that stores recursive information about a given user's login and the parties (positions & 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.

    4. NOTE:  The columns VIS_PR_POS_ID and VIS_PR_BU_ID in the dimensional tables contain the record's primary owning position & 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.
    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.

Position and Organization Initialization Variables

The Siebel Analytics repository contains two preconfigured initialization blocks for Position-based & Organization-based security. These initialization blocks populate the variables PRIMARY_POSTN_ID and ORGANIZATION. The variable ORGANIZATION is a row-wise initialized variable that contains a list of the organizations that the user belongs to. (For more information on row-wise initialized variables, refer to Siebel Analytics Server Administration Guide.) You can set up a similar variable that is a union of all the positions and organizations that the user has access to. To set up such a variable, do one of the following:

Getting the variable directly from the Siebel transactional database requires an understanding of the Siebel data model with reference to security. For each user login, the W_PARTY_LOGIN table has a recursive list of all positions and organizations. The logical equivalent of this setup is:

W_PARTY_LOGIN.PARTY_ID = valueof(NQ_SESSION.POSTN_ORG_UNION)

W_OPTY_PARTY.PARTY_ID = W_PARTY_LOGIN.PARTY_ID and

W_OPTY_PARTY.OPTY_ID = W_OPTY_ID.ROW_ID

In an alternative implementation, use an additional join between W_PARTY_LOGIN and W_[DimensionName]_PARTY instead of using the row-wise initialization. In the case of Opportunities, for example, this can be set up as shown:

W_PARTY_LOGIN.LOGIN = valueof(NQ_SESSION.USER) and

W_OPTY_PARTY.PARTY_ID = W_PARTY_LOGIN.PARTY_ID and

W_OPTY_PARTY.OPTY_ID = W_OPTY_ID.ROW_ID

These two joins have the same effect as the earlier row-wise initialization variable solution, but contain an additional table join.


 Siebel Analytics Installation and Configuration Guide, Version 7.5, Rev. C 
 Published: 18 April 2003