BusinessObjects Board

Combination of Row level security and CMC security

security CMC
#1

Hi,

We are using BOXI 3.0.

We have a complex requirement about security. We have some restrictions coming as from row level security via universe and we have security at CMC level.

I am wondering how people handle that? Can I have the same person in 2 different row restrictions groups? What if they are conflicting? How BO resolves that?

Thanks,
-rk

rit372002 :us: (BOB member since 2006-11-02)

Best Practice for Security Approach?
#2

Yep it’s possible like in previous release I mean from 5.x …

You must specify the priority for each restriction.

#3

we are having a similar issue. In v. 5 we were able to have row level security (set up in Supervisor) to restrict user access to certain values (cost centers). In CMC I cannot find how to establish the same row level security. Is this still possible? If not how can one restrict access to users can only see what they have responsbiity over rather than everything?

Ruben Mestre (BOB member since 2008-11-04)

#4

We do it on the database tables, using a combination of security table and org hierarchy table. It is very simple and very easy to maintain once you have them set up correctly.

substring :us: (BOB member since 2004-01-16)

#5

Do you hvae documentation on how you did it? I am working with our IT department and I’d like to share that information. Thanks

Ruben Mestre (BOB member since 2008-11-04)

#6

Hi

Row/Object level restriction can be done by using Designer in BOXI R2/3.0

jayjaiswal :us: (BOB member since 2008-05-17)

#7

substring’s answer uses a TOTALLY different approach. It involves creating a table at the database level (in your case, cost center to user mapping), and using “normal” Designer functions to enforce that security through joins.

If you are looking to duplicate the Supervisor approach, as jayjaiswal stated the “GUI” to accomplish that has been moved to the Designer client tool, not the CMC web application.

Dwayne Hoffpauir :us: (BOB member since 2002-09-19)

#8

That is correct. The org hierarchy table is a slowly changing dimension table that contains the organizational alignment, e.g. which store belongs to which district, and which district belongs to which region, and so on. The security table contains the user’s org level, e.g. store 101.

You use the @variable(“BOUSER”) to capture the user login. Join that with the security table and the org hierarchy table in your condition object to determine what this user can see and cannot see. In my example, store manager of store 101 cannot see the data for store 102.

It is very simple once you have it set up correctly. And the maintenance is a piece of cake because you can update programmatically… something you cannot do with Designer.

Hope this helps.

substring :us: (BOB member since 2004-01-16)