Column Level Security

[binboy77]

I need to hide some columns in a report that some users don't have the rights to view. e.g if i have a report with SSN along with other columns, only the admin user should be able to see the SSN column in the report while a normal user should not see this column.

This should be done in the same report that needs to be refreshed by different users with different access rights.

Any insights into this would be a great help..!!

Thanks

Bin

 

[BrianTyler]

Bin,

It should not be difficult to hide fields on the displayed report because you always know the logged on user id.

I cannot see how you can stop a user from looking at the data provider and seeing the data, so you will have to return different data depending upon who is refreshing the report.

This means that you will have to change something at the database end. You could have different database views available for different groups of users, or you coluld have a complex CASE statement in the SSN object returning a dummy value for unauthorised users.

Hope this helps a bit


Brian

 

[blom0344]

The answer to this issue is very obvious.
Create versions for both admin AND others users.
Once you create the admin version, then get rid of the secure object and 'SAVE AS' the user version...

Ties Blom
Information analyst

 

[BrianTyler]

Ties,

To be fully secure you would need to generate a new report without the confidential information, otherwise it could be accessed via the data provider in Slice and Dice etc.

Effectively the secure data will have to be fully removed from the query. This does give a double-maintenence requirement.

Bin, are you sure that the Admin user should really have access to that field. If you mean a BO or IT administrator you should think carefully about why they need to see it in such a tool. I recently had a similar problem with Credit Card numbers, and when challenged it seems that the administrators had no real NEED to see them.

Brian

 

[blom0344]

Brian,

AFAIK it is not possible to prevent users from looking into the data manager.
So, whatever one would come up with, if the secure object is fetched in the SQL users will be able to browse through the cube itself.
Hence, it should not be fetched, which leads to different dataproviders and therefore multiple documents.
Frankly I do not see another way around this ...

Ties Blom
Information analyst

 

[binboy77]

Thanks everyone for your responses.
This really throws more light into the issue that there is no straight forward method to achieve the above objective.

What i had tried was to use object level security on the field say ssn. but the problem was that when the report is set as refresh on open and opened by a user for whom the object level security is applied on ssn, he gets an error that he doesn't have the rights to see that object and so the report doesn't refresh. Then i tried including two data-providers, one with ssn and the other without ssn. Why i didn this was thinking that at-least one data provider without ssn would get refreshed. but in this also i get the same error.
don't know why as these are two separate sqls....???

will the BO publisher honour this object level security if i set the report as refresh using the profile of each user?

another approach to this problem can be to use a view which has these built in security and then use table mapping to make BO go against this view for the particular user. using this i can mask the field say ssn with some other valuse say 'XXXXXX' but i can not make the field 'ssn' itself from getting invisible....

please do throw some light with respect to the above.

why i am trying for this is to avoid making 10 different versions of the same report based on 10 different security profiles of users.

thanks again

Bin

 

[BrianTyler]

My approach would be to adjust the objects at the universe level. You would have to include some form of security table in the query to find the access level for the user. Then the SSN field for the query would be described in the universe via a Case statement:

Case when sec_level > 5 then SSN else ' - ' end

 

[skrandel]

You id of table mapping is the best and easiest.

BrianTyler's idea of doing this at the universe level is also good. These are the only solutions I've ever gotten to work for this problem.

Column level security in BO is really only for ad-hoc users and simply does not work for production reports.

Steve Krandel
Symantec