Not sufficient authorization to run a query : multiple authorization

[Former Member]

Hello,

I have ran into an issue way beyond my BW skills concerning authorizations used to restrict Queries data for certain characteristics. I am not sure which information are relevants, so here is all I gathered :

Screenshot of the rsecprot transaction after the Query has failed to run:

[http://f.imagehost.org/view/0113/rsecprot]

As you can see on this screenshot, we want (the query is requesting, I suppose) "AND /BIC/OR_CA4010 = ':' " and the authorization is "OR_CA4010 I CP * " so this okay, and the second part, we want "/BIC/

OR_CA0111/BIC/OR_CA4001 = ':' " and the autorization is only for "OR_CA0111__OR_CA4001 I EQ USA9996" so this is probably the part which fails, since the query is requesting all the data while the user only has access to one value.

In my poor understanding of the issue, it seems that this isn't a normal behavior, one would assume that queries would restrict themselves to allowed data, and this is what actually happens when there is only one authorization involved. However, with two, the mix doesn't seem to work...

What is interesting is that if I set the values for OR_CA4010 (in the variable entry screen) for instance to the values "Node 1" and "Node 2" seen in the rsecprot, then the query is working fine and if I set it to another value, then the query doesn't work , so it seems that the issue isn't really the authorization themselves, but the way we set them up.

Any idea on what the issue may be? Any guidelines on how to set up authorizations in queries ? Maybe we missed something obvious which make it works in most cases but not in this one (since otherwise the queries are working fine, we don't have many user which this kind of authorization set up)

Thank you very much in advance!

Guilaume

[JPReyes]

Moved to Security Forum

[Former Member]

Hi Guillaume,,

>

> As you can see on this screenshot, we want (the query is requesting, I suppose) "AND /BIC/OR_CA4010 = ':' " and the authorization is "OR_CA4010 I CP * " so this okay, and the second part, we want "/BIC/

> OR_CA0111/BIC/OR_CA4001 = ':' " and the autorization is only for "OR_CA0111__OR_CA4001 I EQ USA9996" so this is probably the part which fails, since the query is requesting all the data while the user only has access to one value.

>

If the characteristic is auth-relevant and you have restricted the value in the analysis authorization, then the query within the authorization selection should be good. However, in this case when the query tries to read the data in aggregated form, you need to give access to ":", because you don't want it being '*'. Update the analysis authorization to have value "EQ :" along with USA9996. The query will then display the data.

Hope this helps

Abhishek

[Former Member]

Hello Abhishek,

Thanks for taking a look at my issue

Actually, could you tell me more about this ":" value ? Is it something special? I thought it was the same than "*" but I am not sure. Also, are you suggesting that I authorize both ":" and "USA9996" for this user on this characterstic ? How to do that, since ":" isn't a real value ? ... I think I may have completely misunderstood your idea.

Thanks in advance ~

[Former Member]

Hi Guillaume,

":" does give access to aggravated data.

Check note 1140831, it explains the colon authorization in detail.

>

>are you suggesting that I authorize both ":" and "USA9996" for this user on this characteristic ? How to do >that, since ":" isn't a real value ? 
> Thanks in advance ~

Check the analysis authorization that is giving access to USA9996. Right now, you have this only restricted to this value. After reading the note, you will get an idea, that ":" is not like '*' and does not give full authorization for data, however instead only gives authorization for aggravated data.

":" is a real value that can be entered in the analysis authorization.

Check the note...pretty neat one

Abhishek

[Former Member]

Hi,

Please make the info object as authorization object relevent is RSA1 OR RSD1.if you want maintain info object with master data please make sure that click on with master data under master data/texts tab.if you want to maintain info oject with hierarchy you have to click on with hierarchies.

this infobject has to be add newly customized authorization object .Add the newly created authorization object under S_RS_AUTH.

Regards,

Asif

[Former Member]

Abhishek,

Thanks to you, I am on the way to Enlightment

Indeed, now I understand the error and I can see that it'd be solved by adding the ":" authorization to our user, however, this doesn't satisfy me as I don't understand what part of the query would require this. I have simplified the query to the point where there is only one calculated key figure, and I have restricted this key figure with authorizations on both of the characteristics mentioned in the resecprot. I still get the same "Not sufficient authorization" and the failed "aggregation authorization" check.

So, it all boils down to this : what could make BW want to check for this aggregation? why is it necessary? what is making BW think that there is a need for aggregation beyond the allowed values? The problem is that we never had this issue before, so it's not satisfying to give new authorization to an user without making sure we fully understand the consequences.

Thanks for any further help!

[Former Member]

Alright, I think I have partially answered to this myself : the two characterstics weren't displayed in the query, this is why some aggregation check was made. I added them, and the query still fails, but this time, the rsecprot is giving some different information!

[http://i43.tinypic.com/29z9aat.png]

This doesn't make much sense to me either...

Why is there a "NOT" in the remaining set?!

Looks like another headache is coming...

[Former Member]

Hi Guillaume,

Please check if all the auth-relevant objects have been captured in the AA within the scope of the query. Are you using any authorization variable in the query ? Maybe you need to check that too....probably there might be some missing here itself...

Let us know what you find

Abhishek

[Former Member]

Abhishek,

Thanks for your interest, I'm glad you took a peek at this thread

I am not sure what you are asking tho ... So to make things simpler, I created a very simple query with only the following things :

-> Two characteristics as rows, the two which are mentioned in rsecprot (OR_CA4010 and OR_CA0111__OR_CA4001), as you can see on the previous screenshot

-> Those two characteristics have a restriction in "Default Values" : a variable for each, which have been created as "Processing : By Authorization" (one is a "Hierarchy Node", for OR_CA4010 which has a hierarchy, and the other one is just a "Characteristics Value")

So, as you can see, you can't make it more simple ! And I still get the same error and the same log in rsecprot. Is it any helpful to you ?

Is there anything else I need to check? The authorization given to the user contains values for those two characteristics...

This is driving me crazy

[Former Member]

Hello,

The issue was that we had authorizations on two different dimensions at once (for instance, Country / Account) and that BW is unable to handle this kind of authorisations in the way we were hoping it would.

We wanted to have all data which would be either in the relevant Country OR the relevant Account, but by default the system treats it as the intersection between both Country AND Account.

The proposed solution by a SAP consultant was to create a template, with two sub queries, both the same except that the authorization check would be put on different objects (once on Country, once on Account), then merge the two with the template. This wasn't practical as we had a large amount of queries.

In the end, we changed the business requirements