Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
When the security levels defined for applications, databases, users, and groups are not enough, Analytic Services security filters give you control over security at the most detailed level. Filters let you control access to individual data within a database, by defining what kind of access is allowed to which parts of the database, and to whom these settings apply.
If you have Supervisor permissions, you can define and assign any filters to any users or groups. Filters do not affect you.
If you have Create/Delete Applications permissions, you can assign and define filters for applications you created.
If you have Application Designer or Database Designer permissions, you can define and assign filters within your applications or databases. For descriptions of permission levels, see Understanding Security and Permissions.
This chapter contains the following sections:
Filters control security access to data values, or cells. You create filters to accommodate security needs for specific parts of a database. When you define a filter, you are designating a set of restrictions upon particular database cells. When you save the filter, you give it a unique name to distinguish it from other filters, and the server stores it in ESSBASE.SEC
, the security file. You can then assign the filters to any users or groups on the server.
For example, a manager designs a filter named RED, and associates it with a particular database to limit access to cells containing profit information. The filter is assigned to a visiting group called REVIEWERS, so that they can read, but cannot alter, most of the database, while they have no access at all to Profit data values.
Filters are composed of one or more access settings for database members. You can specify the following access levels and apply them to data ranging from a list of members to an individual cell.
Note:
The MetaRead access level overrides all other access levels. If additional filters for data are defined, they are enforced within any defined MetaRead filters.
If you have assigned a MetaRead filter on a substitution variable, then try to retrieve the substitution variable, an unknown member error occurs, but the value of the substitution variable gets displayed. This is expected behavior.
Metadata security cannot be completely turned off in partitions. Therefore, do not set metadata security at the source database; otherwise, incorrect data may result at the target partition.
When drilling up or retrieving on a member that has metadata security turned on and has shared members in the children, an unknown member error occurs because the original members of the shared members have been filtered. To avoid getting this error, be sure to give the original members of the shared members metadata security access.
Any cells that are not specified in the filter definition inherit the database access level. Filters can, however, add or remove access assigned at the database level, because the filter definition, being more data-specific, indicates a greater level of detail than the more general database access level.
Note: Data values not covered by filter definitions default first to the access levels defined for users and second to the global database access levels. For a detailed discussion of user access levels, see Granting Permissions to Users and Groups. For a detailed discussion of global access levels, see Managing Global Security for Applications and Databases.
Calculation access is controlled by minimum global permissions or by permissions granted to users and groups. Users who have calculate access to the database are not blocked by filters-they can affect all data elements that the execution of their calculations would update.
You can create a filter for each set of access restrictions you need to place on database values. There is no need to create separate filters for users with the same access needs-once you have created a filter, you can assign it to multiple users or groups of users. However, only one filter per database can be assigned to a user or group.
Note: If you use a calculation function that returns a set of members, such as children or descendants, and it evaluates to an empty set, the security filter is not created. An error is written to the application log stating that the region definition evaluated to an empty set.
Before creating a filter perform the following actions:
To create a filter, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
Figure 209 illustrate different ways to control access to database cells. Data can be protected by filtering entire members, or by filtering member combinations.
Figure 209: How Filters Affect Data AND/OR Relationships
Note: Filtering on member combinations (AND relationship) does not apply to MetaRead. MetaRead filters each member separately (OR relationship).
To filter all the data for one or more members, define access for each member on its own row in Filter Editor. Filter definitions on separate rows of a filter are treated with an OR relationship.
For example, assume that user KSmith is assigned this filter:
Figure 210: Filter Blocking Access to Sales or Jan
Access |
Member Specification |
---|---|
The filter blocks access to all members Sales or Jan in the Sample Basic database.
The next time user KSmith connects to Sample Basic, she has no access to data values for the member Sales or for the member Jan. Her spreadsheet view of the profit margin for Qtr1 looks like this view:
Figure 211: Results of Filter Blocking Access to Sales or Jan
All data for Sales is blocked from view, as well as all data for January, inside and outside of the Sales member. Data for COGS (Cost of Goods Sold), a sibling of Sales and a child of Margin, is available, with the exception of COGS for January.
To filter data for member combinations, define the access for each member combination using a single row in Filter Editor. A filter definition using one row and a comma is treated as an AND relationship.
For example, assume that user RChinn is assigned this filter:
Figure 212: Filter Blocking Access to Sales for Jan
Access |
Member Specification |
---|---|
The filter blocks only the intersection of the members Sales and Jan in the Sample Basic database.
The next time user RChinn connects to Sample Basic, she has no access to the data value at the intersection of members Sales and Jan. Her spreadsheet view of the profit margin for Qtr1 looks like this view:
Figure 213: Results of Filter Blocking Access to Sales, Jan
Sales data for January is blocked from view. However, Sales data for other months is available, and non-Sales data for January is available.
You can use filters to restrict access to data for base members sharing a particular attribute. To filter data for members with particular attributes defined in an attribute dimension, use the attribute member in combination with the @ATTRIBUTE function or the @WITHATTR function.
Note: @ATTRIBUTE and @WITHATTR are member set functions. Most member set functions can be used in filter definitions.
For example, assume that user PJones is assigned this filter:
Figure 214: Filter Blocking Access to Members with Attribute "Caffeinated_False"
Access |
Member Specification |
---|---|
The filter blocks access to data for caffeine-free products. "Caffeinated_False" is a Boolean-type attribute member in Sample Basic, in the Pkg_Type attribute dimension. This attribute is associated with members in the Product base dimension.
The next time user PJones connects to Sample Basic, he has no access to the data values for any base dimension members associated with Caffeinated_False. His spreadsheet view of first-quarter cola sales in California looks like this view:
Figure 215: Results of Filter Blocking Access to Caffeine-free Products
Sales data for Caffeine Free Cola is blocked from view. Note that Caffeine Free Cola is a base member, and Caffeinated_False is an associated member of the attribute dimension Caffeinated (not shown in the above spreadsheet view).
You can perform the following actions on filters:
To view a list of filters, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
To edit an existing filter, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can copy filters to applications and databases on any Analytic Server, according to your permissions. You can also copy filters across servers as part of application migration.
To copy an existing filter, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
To rename an existing filter, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
To delete an existing filter, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
Once you have defined filters, you can assign them to users or groups. Assigning filters to users and groups lets you manage multiple users who require the same filter settings. Modifications to the definition of a filter are automatically inherited by users of that filter.
Filters do not affect users who have the role of Supervisor. Only one filter per database can be assigned to a user or group.
To assign a filter to a user or group, see "Assigning Filters" in the Essbase Administration Services Online Help.
If a filter contains rows that have overlapping member specifications, the inherited access is set by the following rules, which are listed in order of precedence:
For example, this filter contains overlap conflicts:
Table 33: Filter with Overlap Conflicts
Access |
Member Specification |
---|---|
The third specification defines security at a greater level of detail than the other two. Therefore Read access is granted to all Actual data for members in the New York branch.
Because Write access is a higher access level than None, the remaining data values in Actual are granted Write access.
All other data points, such as Budget, are accessible according to the minimum database permissions.
Note: If you have Write access, you also have Read access.
Changes to members in the database outline are not reflected automatically in filters. You must manually update member references that change.
When the access rights of user and group definitions overlap, the following rules, listed in order of precedence, apply:
User Fred is defined with the following database access:
FINPLAN R CAPPLAN W PRODPLAN N
He is assigned to Group Marketing which has the following database access:
FINPLAN N CAPPLAN N PRODPLAN W
His effective rights are set as follows:
FINPLAN R CAPPLAN W PRODPLAN W
User Mary is defined with the following database access:
FINPLAN R PRODPLAN N
She is assigned to Group Marketing which has the following database access:
FINPLAN N PRODPLAN W
Her effective rights are set as follows:
FINPLAN R PRODPLAN W
In addition, Mary uses the filter object RED (for the database FINPLAN). The filter has two filter rows:
Figure 216: RED Filter for Database FINPLAN
Access |
Member Specification |
---|---|
The Group Marketing also uses a filter object BLUE (for the database FINPLAN). The filter has two filter rows:
Figure 217: BLUE Filter for Database FINPLAN
Access |
Member Specification |
---|---|
Mary's effective rights from the overlapping filters, and the permissions assigned to her and her group, are as follows:
For additional sample scenarios, see Security Examples.
![]() |