BI 7 - assign ' : ' analysis auth for all auth relevant info objects

[Former Member]

Hi all,

In BI 7, when you have multiple info objects flagged as authorization relevant, does this then require a specific role providing analysis for all these info objects with u2018 : u2018 value and this provided to all users?

As I understand correctly, when such an info object is flagged, the system is looking if you have authorization on this (A) if itu2019s used in the query. But if the query is designed to be protected by another info object (B) , it will still require a u2018 : u2018 value for (A).

So is it a good approach to build 1 role with u2018 : u2019 analysis authorization and assign this to the users, so they donu2019t have problems with queries that check on authorization relevant info objects which are not used to protect the query at that point?

Query (D) is using 0Customer, 0Profit center u2026 and should be protected on 0profit center only.

0Customer and 0Profit center are authorization relevant..

The end user has been provided with analysis auth for the profit centers he is allowed to get data from.

The system will check if the end user has u2018:u2019 authorization for 0Customer.

I hope my question is a bit clear.

Thanks in advance

Kristof

[dannysprangers2]

Hello,

I thought ':' was meant for summation levels. What I do for authorisations is the following :

Only put infoobjects authorisation-relevant which are needed to check. Normally the list of such infoobjects should be limited

Than create for each auth-relevant infoobject at least 1 object in trx RSECADMIN. If you don't know what must be restricted, if nobody can say this to you, maybe it's not needed to restrict or otherwise create the object with a '*' as value and assign this to the user. In this case 0customer will be checked but the user has full authorisation.

[arpan_paik]

I thought ':' was meant for summation levels

[Former Member]

Hi Krestof,

Check note:1053989 it can help in understanding pattern of restriction in analysis authorization.

Cheers

[Former Member]

Thanks for the replies.

But what to do if you have this case:

2 sets of queries:

set 1: queries that should be protected on 0Customer (and also contain profit center)

set 2: queries that should be protected on 0Profit Center (and also contain profit center)

End user A has the authorization for the profit centers he has to access. The same for his restriction on 0Customer.

End user B should only be able to have the authorization for his list of profi centers, but no authorization for 0Customer. In this case it is not possible to give * authorization for 0Customer, that's why I thought that the ' : ' would do the trick. Because for user B, that system is searching for 'some' authrozation for 0Customer (because it's also authorization relevant).

Regards,

Kristof

[dannysprangers2]

Hello Kristof,

if user B has access for a limited list of profit_centers, but no authorisation for 0customer, it won't be possible to execute a query where 0customer is on the selection screen or rows/columns. Because this is meaning he maynot see any customer. So create a query whithout 0customer and he will only see his profit-centers.

[Former Member]

So best is to create a query using only 1 authorization relevant info object in it? And no use of other authorization relevant objects in the same query?

grtz

Edited by: Kristof Smets on Feb 3, 2010 12:20 PM

[dannysprangers2]

Remove all the infoobjects from the query which are authorisation relevant and where the user may not have authorisation for. Authorisations in BI handle the formula : 'All are nothing', meaning or you are allowed by authorisations to see results or when 1 object is missing the user gets nothing. So in your case, remove 0customer and keep the other authorisation relevant objects. If this is only 0profit_center, then yes you'll get a query with just that 1 object.

[Former Member]

Kristof,

With BI Analysis auth concept, user has to have at least aggregate ( authorization for all auth-relevant info-objects from an info-provider so as to execute any query on it. It doesn't matter if query refers to the Auth-relevant info-object or not.

Queries are created based on business requirement, BI analyst/power users may use any InfoObject , it's business that drives whether InfoObject need to be protected or not.

In your case you can create two separate AAs for user A and user B. AA for user A can have specific values for profit center and customer. AA for user B will have specific profit center values, however will have : for 0cusomer. That way both users can execute the queries.

It's good practice to always put aggregate authorization in AA for every infoobject along with their specific value authorization.

Regards,

Amol