Where can we find organizational fields maintained in reporting authorization when RSR was used in cases of BW<=7.3

[Former Member]

Hi Team,

Our Project is undergoing a BW Security upgrade from 7.0 to 7.3. Security part has not started yet. Currently we are planning on the approach to build analysis concept for the existing Reporting ones

We are not using Analysis authorization in our current concept. We are still using the old reporting concept though it is 7.0.

Now that Analysis authorization is mandatory in 7.3 we have to redesign our existing reporting Roles to Analysis authorization concept.

I picked up a role and tried converting it to analysis and have got few doubts while doing so. If someone could help me resolve that it would be great.

Well, my old Role had S_RS_comp which gives query access and many S_RS_* objects which gave the data access.

I tried to put in the auth relevant infoobjects from the queries that were under S_RS_COMP and built a analysis auth. Now my problem is I am not able to make out what value should these infoobjects like Plant. profit center and all should hold.

Because in the old reporting Role, I do not see org fields nor their value. I wonder from where the user would get these values. Infact our current BI system do not have any Roles which has org values, I would say AGR_1252 is almost empty

Is there any S_RS_* object and field from the reporting Roles which does this, or shoud I check the RSA1 tcode for this, or should I inquire the BI consultant which org fields  does this query pull out,or could it be the case in our client that the query itself would not let any authorization checks for these org fields??

Regards,

Preethi

[Colleen]

Hi Preethi

In the old conecept in RSSM, each multiprovider can have the characterisic set as auth relevent. Custom auth objects are then build and maintained in PFCG. In the new concept, the characteristics is set as auth relevent system-wide in RSD1. To work out what you need to build:

You will need to work closely with BI Development team as the RSD1 settings can impact queries that use a cube, where in RSSM that characteristic was not auth relevant. You will also need to know if the RSECADMIN values should be maintained as hierarachy or values/ranges.

A quick way to obtain all of the auth relevant characteristics, navigation attributes, etc is to go to RSECADMIN and look at the 0BI_ALL analysis authorisations. It is automatically updated when RSD1 settings are changed.

I recommend you read up on transaction RSECADMIN and learn about the way to trace analysis authorisation build concepts

Regards

Colleen

[Former Member]

Hey Colleen,

Thanks for your detailed reply, Even I was wondering that there should be custom objects , but I dont see any.

As you said need to get in touch with the BI Dev team and clarify this.

Regards,

Preethi

[Former Member]

Hi,

In addition to Colleen's thorough response there are a couple of other things to check

1. Are you using authorisation variables?

2. Do you have separate data roles? It is a common design technique to have query/functional access in one (or more) role/s and a separate data role.

[Former Member]

Hi Alex,

Thanks for the additional information.

I have never heard of Authorization variables, probably I need to work on understanding that .

We do not have separate data Roles, I still wonder where and how the users are getting data access from !!

One more question which I wanted to ask was  when should the SPRO step of activating analysis authorization be executed. Is it after the SU25 upgrade or before that??

Regards,

Preethi

[Former Member]

May be worth asking your BW team if they are using variables.  It's also worth considering that if no characteristics have been made auth relevant (in 7.0) then there won't be checks on the data - worth a check.

For the activation of AA concept - the last couple of times I have done it I did it post-SU25.

[Former Member]

Thanks Alex.

I have already checked the system and there are few characteristics which have been made auth relevant.. but I dont see them used anywhere for a auth check.

Regards,

Preethi

[Former Member]

Actually is sounds as if the old concept used only "all or nothing" access to the infocubes to permit the access and within the cube the visibility of the query was used as control. The query is possibly passing the org values as fixed parameters.

This approach is not unusual in older systems and of course very easy to migrate to the new concept.

Downside is that if the user can influence a parameter or run queries of their choice, then you have no security on the data anymore.

I wager a bet that that is the case here and will eat my hat if I am wrong...  🙂

Cheers,

Julius

[Former Member]

Julius von dem Bussche wrote:
I wager a bet that that is the case here and will eat my hat if I am wrong...  🙂
Cheers,
Julius

You haven't eaten the last one yet

[Former Member]

Hi Julius,

As we are beginning to investigate on the system , we even have no idea on what tool are the end users using to get the reports.

I additional thing I have noticed is there are customized portal Roles in the UME which some of the users are getting access to and some of our reporting Roles are assigned with.

Does this have to do anything with the data access users are getting as I see nothing else providing data access to them in the backend.

Regards,

Preethi

[Former Member]

I additional thing I have noticed is there are customized portal Roles in the UME which some of the users are getting access to and some of our reporting Roles are assigned with.

I raise Alex and Coleen one more hat with a solar powered propeller on top and a set of "his and hers" pocket protectors...  🙂

If you look in those queries which are published via the roles, then you will see that the org.level values are passed as parameters. So it is a question of which query the user can see and not which access they have.

This is however not all bad. Many customers do have open book policy for reporting and controlling and have a "so what" attitude towards any risk of a user seeing some other unit's sales data or profit margins or where the manager put petrol in their cars on weekends etc...

Cheers,

Julius

[Former Member]

Now this means if S_RS_PARAM is a * and correct parameter for org fields are maintained in the SU01, the users gets these org field's access !!

Is this how it works??

Regards,

Preethi

[Former Member]

It could even be that these are user parameters. But more common is to find that the queries have selection parameters and the menu transaction in the role is passing the parameter values to the query.

Based on your description, the 2nd option sounds more likely.

Cheers,

Julius

[Former Member]

Hi Preethi,

There are a few ways that restriction over data could be achieved, we have covered some of them here, there are a few more.

When this is relating to your own environment then the first place to be checking is with your BW team.  Once you have confirmed how (if any) they are restricting, whether that is through report variants, hard-coded selection options, organisational splits in multiproviders (unlikely but I have seen it), authorisation variants etc, then we can help with your approach for your analysis auth build.

[Colleen]

I raise Alex and Coleen one more hat with a solar powered propeller on top and a set of "his and hers" pocket protectors...  🙂

I go to sleep and wake up to find that I owe you a hat with a solar powered propeller on top and a set of "his and hers" pocket protectors! If only I know how (translation: could be bothered), I'd turn this request into a bitstrip and send your way! It'd be a great profile pic.

Old Concept, New Concept, how it's all restricted comes back to one common theme: talk to your developer and find out what they did. We can only restrict and build what they accommodate.

Thanks for the laugh Julius - a great way to start my morning!

Cheers

Colleen