by Kurt Wolff

Suppose you have a dashboard with three pages (tabs). Suppose further that not every user should see all three tabs. Most users will see a limited set of the tabs – some will see two, some will see only one. You want to define web groups to cover all the possible combinations. How many web groups would you have to create?

The combinations are:

321
32
31
21
3
2
1

So you would have to define 7 web groups.

Suppose there are five tabs. With five tabs there are 31 combinations.

Suppose there are ten tabs. Now there are 1023 combinations.

In general, for a collection of n things, there are 2^n-1 combinations.

Clearly, even with only 10 tabs, you cannot define web groups to cover all combinations.

The problem is made more difficult by the fact that OBIEE only tells you which web groups have permission to access a web object. It does not tell you which objects a particular web group has permission to access. This means that, for any given user, you cannot predict what his/her experience will be after logging into OBIEE.

Web security gets messy very fast.

One way to deal with this is to create a single web group for every object. That means that there will be at most only n web groups, not 2^n-1. (Both n and 2^n-1 are theoretical combinations for read permission. There could be another set of web groups for full control or other permissions). Then assign membership to the web groups using row-wise initialization at log on.

A sample table of users and web groups might contain these entries for users K and G. K is a member of Tab11, Tab13, and Tab15 web groups.  G is a member of Tab11, Tab12, Tab14, and Tab16.

When K logs on she sees these tabs:

When G logs on, he sees these:

With this approach, it is also easy to predict (or audit) the experience of each user simply by querying the table. It would also be easy to create an application (outside of OBIEE) to assign permissions to users.