Oracle BI EE 11g - Decoding Essbase Connectivity - Part 5 - Security

Venkatakrishnan J -

I was actually compiling all my findings of the last 4 posts as a summary post but then realized i haven't actually covered another important part of the Essbase Connectivity i.e. Essbase Security. In today's post let's look at how Essbase Security is handled in BI EE 11g. I will follow this one with the summary posting. Essbase provides 2 types of data level security. They are

1. Data Level Filters

2. Meta Read Filters

Data Level filters hide the data values of the members. But the members themselves are visible. On the other hand Meta Read Filters provide data and member level security.

Data Level Filters:

To test this we start off with creating a user in shared services called as secuser. This user is provisioned to access the Demo > Basic cube. Also, a filter is created to provide access only to the IDescendants of the West Market member.

I believe there is a bug in the Admin Console UI of Essbase 11.1.2. It does not allow the admin user to assign filters to other users. Thanks to Glenn, just realized that the filter assignments have moved over to SS. So, lets assign the created filter to the user through MaxL instead.

grant filter 'Demo'.'Basic','MarkFilt' to user secuser;

Let's now update the connection pool settings of the repository to connect to Essbase using the above created user.

Let's now create a report containing the hierarchical Market column and a measure as shown below.

This works as expected. Typically EAS will generate #No Access values for all the cells for which the user does not have access.

Meta Read Filters:

Now that we have tested the data level filters, lets test the metaread filters. To test this, let's create one more user called metareaduser who will have access to all members under the West member of the Market dimension. Very similar to the data level filter use case above but this one will provide dimension member level filtering capability.

Let's now update the connection pool of the RPD with the new user and then test whether the above security works.

Again this works as expected. Let's now find out what happens during the drill if we assign a metaread filter to the lowermost level i.e. on the Seattle member instead of West.

This is very good. As you see whenever we assign a metaread filter to the lowermost level, we still see the branch from root leading up to that member (with data level security applied). That way we can have security applied at any level in a hierarchy and we still will have a seamless drill experience.