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)