Supervisor - row level restrictions

security Supervisor (4.x - 6.x)
1

Hi All,
I’ve seen a problem pertaining to BO Supervisor row level restrictions .We are using BO 417 and have to put some restrictions on one of our Customer tables .Upto 4 conditions its working fine but as i’m trying to put the 5th condition for the same table its not accepting ;in the rows tab of Universe->Properties after sayin’ OK and again going to see the same row restriction the 5th condition disappears .Is there some limitation for the length of where clause in Supervisor row level restrictions dialog box (thou it shouldn’t be …) ?
Has anyone ever been into such situation ? Any suggestions will be highly appreciated …

Thanks,
Vikas Vats
_________________________________________________ g GE, Lighting, Cleveland
Consultant, TCS
Tel # 216-266-8923(Off)
Dial Comm 8-346-8923
440 442 0169(Res)

Listserv Archives (BOB member since 2002-06-25)

2

X-cc: “Vikas.Vats@LIGHTING.GE.COM” Vikas.Vats@LIGHTING.GE.COM

Hi All, I’ve seen a problem pertaining to BO Supervisor row level restrictions .We are using BO 417 and have to put some restrictions on one of our Customer tables .Upto 4 conditions its working fine but as i’m trying to put the 5th condition for the same table its not accepting ;in the rows tab of Universe->Properties after sayin’ OK and again going to see the same row restriction the 5th condition disappears .Is there some limitation for the length of where clause in Supervisor row level restrictions dialog box (thou it shouldn’t be …) ?
Thanks, Vikas Vats

I think there is a 254 character restriction on row level security (at least in BO v4.1x). I’d bet that’s causing your 5th security condition to drop - I’ve had this happen to me a bunch of times and I eventually had to alter the tables involved so that I could get the field names smaller. It seems pretty ridiculous that this limitation has yet to be addressed by BO but I’ve never seen it documented either. Can anyone else confirm or deny the 254 character limit? Thanks - Scott

Listserv Archives (BOB member since 2002-06-25)

3

This is relevant to the row level restrictions discussion. I meant to post it publicly earlier but just haven’t had the chance…

It addresses the ‘254 character restriction’ and provides a sql to pull restrictions out of the db by userid…

Listserv Archives (BOB member since 2002-06-25)

4

I think there is a 254 character restriction on row level security (at
least
in BO v4.1x).<

Further to a couple of messages on this subject and the one on tableowner.tablename, could I raise a related query.

I need complex row level security where some fields for some rows need to be excluded. A consultant from Business Objects has told me this isn’t possible. I have tried a couple of experiments and am planning to try the following as it seems to work. I would be grateful if anyone could highlight any risks they can see before I implement.

Using BO 5.0.1 and Oracle 7.3.4 (possibly 8).

Create the universe without the tableowner specified in the schema. Create views of the relevant tables with the relevant row/column combinations anonymised for the different groups. Create a schema for each group.
Create synonyms of tablename pointing to the views within the relevant schema
In supervisor force the connection for the group to the created schema.

Providing I manage the joins to ensure outer joins on anonymised columns, I would expect the group connection to use the view via the sysnonym rather than the table.

How does this sound?

Jonathan Bliss, Product Consultant
McKessonHBOC Computer Centre,
Harold Wood Hospital site, Gubbins Lane, Romford, RM3 0NE mobile:0498 668084, tel 01708 336135 (direct line with voicemail), fax 01708 376270

Listserv Archives (BOB member since 2002-06-25)

5

In a message dated 00-03-21 04:51:37 EST, you write:

I need complex row level security where some fields for some rows need to be
excluded. A consultant from Business Objects has told me this isn’t possible. I have tried a couple of experiments and am planning to try the following as it seems to work. I would be grateful if anyone could highlight any risks they can see before I implement.

Using BO 5.0.1 and Oracle 7.3.4 (possibly 8).

Create the universe without the tableowner specified in the schema. Create views of the relevant tables with the relevant row/column combinations anonymised for the different groups. Create a schema for each group.
Create synonyms of tablename pointing to the views within the relevant schema
In supervisor force the connection for the group to the created schema.

Providing I manage the joins to ensure outer joins on anonymised columns, I would expect the group connection to use the view via the sysnonym rather than the table.

How does this sound?

Jonathon:

Why go to all the trouble of setting up a different schema? From reading your steps, it seems that you could do the following:

Create the universe without the tableowner specified in the schema.
Good start

Create views of the relevant tables with the relevant row/column
Yes, do this…

combinations anonymised for the different groups. Create a schema for each group.
Create synonyms of tablename pointing to the views within the relevant schema
In supervisor force the connection for the group to the created schema.

Instead of doing all of these steps, why not just use the table mapping features of BusObj? In other words, if I am a limited user, map FULL_TABLE into RESTRICTED_VIEW using Supervisor. Then I only see the columns that I am eligible for. You would then have to revoke access to those objects that I can no longer see.

You can repeat these steps for different sets of users. So, users in group A would map FULL_TABLE to RESTRICTED_VIEW_A and would not be able to see any objects based on columns that don’t appear in their view. Users in group B would map FULL_TABLE to RESTRICTED_VIEW_B and would likewise have missing objects revoked.

I think this would be easier to represent than using a different connection. Table mapping replaces all references to the mapped table, so it affects joins and objects at the same time. This will also use any contexts that you may have set up in the universe, as the contexts have to be resolved first, and then the table mapping occurs.

Food for thought…

Regards,
Dave Rathbun
Integra Solutions
www.islink.com

Listserv Archives (BOB member since 2002-06-25)