Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BI Security questions

Former Member
0 Kudos

1.What is the best practice to assign infobjects for Activity, Infoprovider and Validity to all users? What are the different approaches that companies take to assign these mandatory authorizations to users?

2.What are the factors that determine which infoobjects need to go into a particular analysis authorization?

3.Searching:If I need to find out all the analysis authorizations having a particular value of a infoobject- eg: Activity=02, how can we accomplish this?

1 ACCEPTED SOLUTION

Former Member

Firstly, i'd think that assignment of these mandatory infoObjects / other infoObjects as well as the analysis authorizations themselves would be more important from an end/business users standpoint.

By default when the infoObject 0TCAACTVT is added to an Analysis authorization, it has the value 03 populated which should suffice for report execution.

With regards to infoObject 0TCAIPROV, it would be a good practise to restrict the user to the Infoproviders on which the reports he executes are based, especially since, in a lot of Security designs, we tend use the practise of wild cards/patterns for report names authorization (S_RS_COMP / COMP1).

eg: authorization to execute reports ZSD* , ZFI* etc...

But there could be exceptions where this infoObject can have a * for endusers with restricted authorizations. For example, in the current security implementation design i am working with, a single user is authorized to execute reports from a cross section of modules like ZFI (finance), ZSD (Sales and distribution), ZINV (inventory / MM). In this case i cant use the wild cards, because the user is allowed access to some but not all reports of these modules. SO i am forced to restrict by invidual report names. In this case, since i am restricting at a lower level (report name) i dont need to bother about restricting at a higher / generic level (Info provider).

Comming to the third object, 0TCAVALID the most common value, that i believe, would be used is *.

But this infoObject can use operators which the other infoObjects are not allowed ( NE- not equal to, LE-less than or equal to, GT- greater than, GE, etc) since it uses dates as value. The other infoObjects can only use CP, BT and EQ.

For you final question regrding "search", use table RSECVAL

Analysis authorizations have more significance for end/business users than super/admin users as they deal with restriction at Data level.

Regards,

Prashant

3 REPLIES 3

Former Member

Firstly, i'd think that assignment of these mandatory infoObjects / other infoObjects as well as the analysis authorizations themselves would be more important from an end/business users standpoint.

By default when the infoObject 0TCAACTVT is added to an Analysis authorization, it has the value 03 populated which should suffice for report execution.

With regards to infoObject 0TCAIPROV, it would be a good practise to restrict the user to the Infoproviders on which the reports he executes are based, especially since, in a lot of Security designs, we tend use the practise of wild cards/patterns for report names authorization (S_RS_COMP / COMP1).

eg: authorization to execute reports ZSD* , ZFI* etc...

But there could be exceptions where this infoObject can have a * for endusers with restricted authorizations. For example, in the current security implementation design i am working with, a single user is authorized to execute reports from a cross section of modules like ZFI (finance), ZSD (Sales and distribution), ZINV (inventory / MM). In this case i cant use the wild cards, because the user is allowed access to some but not all reports of these modules. SO i am forced to restrict by invidual report names. In this case, since i am restricting at a lower level (report name) i dont need to bother about restricting at a higher / generic level (Info provider).

Comming to the third object, 0TCAVALID the most common value, that i believe, would be used is *.

But this infoObject can use operators which the other infoObjects are not allowed ( NE- not equal to, LE-less than or equal to, GT- greater than, GE, etc) since it uses dates as value. The other infoObjects can only use CP, BT and EQ.

For you final question regrding "search", use table RSECVAL

Analysis authorizations have more significance for end/business users than super/admin users as they deal with restriction at Data level.

Regards,

Prashant

0 Kudos

Hello Prashanth,

Thanks for your reply. I greatly appreciate your reply to my thrid question. But let me clarify my first two questions:

Here is my 1st question:

Infoobjects for activity,infoprovider and validity need to be assigned to all users,right? So what is the best practice to do this? Is it to create a common role with these three charecteristics and assign it to all users? Is there a better way to do this?

My second question:

When you build a new analysis authorization in response to a no authorization message, what charecteristics need to be included in this auth? How can we determine this?

0 Kudos

>

> Here is my 1st question:

> Infoobjects for activity,infoprovider and validity need to be assigned to all users,right? So what is the best practice to do this? Is it to create a common role with these three charecteristics and assign it to all users? Is there a better way to do this?

>

Not to all users. However, you can create a basic Analysis Auth Object that would give common bare minimum access to an infoarea and then add additional AA Objects to make the role specific for a certain task / query access

>

> My second question:

> When you build a new analysis authorization in response to a no authorization message, what charecteristics need to be included in this auth? How can we determine this?

Well, it all depends on the type of authorization message, it may not be due to AA it may be due to lack of authorization for S_RS_ICUBE or something else. ST01 trace and RSECADMIN traces would help you

PS : Have you tried any of this practically or you are asking only theoretically, this well help anyone explain you with that perse. You may search in SDN and you'll get cases for these questions and you can analyse them case by case

Cheers!!

Zaheer