Isolating data on BW reports to specific users with Analysis Authorizations

[Former Member]

Since migrating to the new way security in handled in BW using Analysis Authorizations we have come across some challenging issues when looking at addressing accesses for isolated users.  The issue we have is that if we want to create an authorization restriction on a characteristic or navigational attribute, that restriction is applied to all infocubes and multiproviders that contain that particular characteristic.  This would be fine if our audience and data were static but in our case, this doesn’t work.  For example, we may have a cube with sensitive data that requires certain groups to be restricted to their own specific company code.  In another cube, we have data in which there is no sensitive data and therefore no restriction on company code.  If we create authorization restrictions on company code, then the restriction is automatically applied to all cubes and multiproviders that hold the company code characteristic which means that all queries using those infocubes and multiproviders must be modified to accommodate the restriction for the specific user set.  If all of the queries have to change then every report that uses them must be tested regardless of whether the particular report is supposed to be restricted or open.  So my question is, how can we create a restriction on a characteristic that applies to only certain cubes?

Kind regards,

Doug Helton

[shivraj_singh2]

Doug,

You will have to create multiple Company Code analysis authorizations just like creating different roles if you were trying to restrict Company Code as org level.

General design will be as below:

Analysis Authorization for InfoProviders with no sensitive data

0TCAACTVT   03

0TCAIPROV    [No Sensitive Data InfoProviders]

0TCAVALID    *

0COMP_CODE  [*]

Analysis Authorizations for InfoProviders with sensitive data

0TCAACTVT   03

0TCAIPROV    [Sensitive Data InfoProviders]

0TCAVALID    *

0COMP_CODE  [Value]

Regards,

Shivraj

[Former Member]

Hi Shivraj,

Thank you for your reply.  I can understand the part about creating the multiple analysis authorizations.  However, it doesn't take care of the other issues that this entails.  For example:

My system has a multiprovider cube that has a characteristic or navigational attribute that I wish to secure and make authorization relevant.  I then create the appropriate analysis authoriztions as you indicate above.  What I am being told my my developers is that every query that uses that multiprovider must now be changed to accomodate the secured characteristic/nav attribute regardless if it is applicable to the report produced by the query.  That then leads to additional testing of all reports served by the multiprovider to ensure they still function correctly.  What I've found is that every user will then have to have the correct analysis authorization even if the report using the multiprovider isn't concerned with isolating the data. 

I hope there is a better way to build this as it seems counterproductive.

Regards,

Doug

[shivraj_singh2]

Douglas,

(1) Once an InfoObject is marked auth-relevant, it will get auth-checked for all the InfoProviders it is present in.

(2) For the InfoProviders already in use, you are going to have two scenarios

(i) there is no data for the InfoObject in InfoProvider & the InfoObject is not used in any of the queries written on the InfoProvider – it will be the case of [No Sensitive Data InfoProviders] – you can update the [No Sensitive Data InfoProviders] analysis authorization with such InfoProviders OR to be more safe you can build analysis authorization similar to [No Sensitive Data InfoProviders] – but for InfoObject value use (:) instead of (*). You will not need to update the queries for auth-variables for this new auth-relevant InfoObject as it is not used in the queries. However you will need to re-test the queries for auth-check failure, spot check will be fine, just test one query per such InfoProvider.

(ii) There is data for the InfoObject in InfoProvider & the InfoObject is used in the queries - it will be the case of [No Sensitive Data InfoProviders] – you can update the [No Sensitive Data InfoProviders] analysis authorization with such InfoProviders and keep the (*). You can update the queries for auth-variable, although it is redundant but it will take care of the case when you want to remove (*) access from these queries in future. Again spot test such queries one per InfoProvider.

  The new analysis authorization concept is more detailed & powerful than the previous reporting authorization concept – so you also need more detailed requirement. Frequently changing requirement is going to be a pain to accommodate in security design. The first step is always going to be deciding what objects need to be secured and thus marked auth-relevant. It may sound more daunting of a task than it actually is.

Regards,

Shivraj