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: 

weird issue: auth check ignoring asterisk

Former Member
0 Kudos

A user in BW 3.5 is assigned one role that has a few auth objects including S_RS_COMP.   He is getting an auth failure that we can see in ST01 trace.  But the role gives all values seen in the ST01 error....the user master is compared, and the role is generated and green status.  This user should NOT get an auth failure, he definitely has all values seen in the failure.   Here is the weird thing, when I  edit the role to remove the asterisk in RSZCOMPTP and replace with explicit values (OWZ, REP), it works.   I can't explain it.   If I put it back to *, it fails.   Is this a bug?  Has anyone else seen something like this?

8 REPLIES 8

Former Member
0 Kudos

Hi,

I wonder what will happen if you give the user sap_all.

bye Jan van Roest

Former Member
0 Kudos

Hi,

Can you please perform a RSSM trace and let us know if you find anything new ? You can also check if the specific values are hard coded within the ABAP code or not. If yes, then the authorization check will ignore the asterix(*).

Regards,

Dipesh.

0 Kudos

Really?  that is possible?  I thought even if ABAP hardcodes an explicit value for an auth check, the authorization routines see the * and returns true.  Can someone elaborate on this, under which situations is * not treated like as a wildcard?

0 Kudos

Hi,

This particular situation (BW) is a new one for me but I have seen similar behaviour for a couple of the S_ auth objects (I am pretty sure S_LOG_COM was one of them but it was a few years back).

0 Kudos

Thank you Alex.  It is reassuring to know that a knowledgeable person like yourself has observed something similar.  I was tempted to raise an OSS Message about it, but since this is BW 3.5 I doubt SAP would give attention to it, especially since I have a "solution".  

Former Member
0 Kudos

Another possible explanation is that the developer reverse engineered the check -> he first read the values in the authorizations (expecting explicit ones) and then used the authorized values to filter the selected ones and only return that which the user is authorized for.

The correct way would be to perform an authority-check on what was selected, filter that which the user is not authorized for (and possibly tell then how many records were not displayed).

It should authorize on the value * and not go looking for a * in the check table...

If you still have the trace, then please post the coding (double-click the line item and use the "Go to source" button).

Cheers,

Julius

0 Kudos

Trace:

Authorization Obj. : S_RS_COMP

SY-SUBRC           : 4  (No authorization

Program            : SAPLRSSB

Row                :       783

No.of Auth. Values :         5

RSINFOAREA <CONFIDENTIAL>

RSINFOCUBE <CONFIDENTIAL>

RSZCOMPTP  REP

RSZCOMPID  <CONFIDENTIAL>

ACTVT      16

from FM: RSSB_AUTHORITY_COMP_CHECK

Goto Source button take me to the line starting with "ELSE"

    IF NOT i_infoarea IS INITIAL.
      IF NOT i_infocube IS INITIAL.
        IF NOT l_comptype IS INITIAL.
          IF NOT i_compid IS INITIAL.
            IF NOT i_actvt IS INITIAL.
              AUTHORITY-CHECK OBJECT 'S_RS_COMP'
                     ID 'RSINFOAREA' FIELD i_infoarea
                     ID 'RSINFOCUBE' FIELD i_infocube
                     ID 'RSZCOMPTP'  FIELD l_comptype
                     ID 'RSZCOMPID'  FIELD i_compid
                     ID 'ACTVT'      FIELD i_actvt.
            ELSE. "i_actvt is initial
              AUTHORITY-CHECK OBJECT 'S_RS_COMP'
                     ID 'RSINFOAREA' FIELD i_infoarea
                     ID 'RSINFOCUBE' FIELD i_infocube
                     ID 'RSZCOMPTP'  FIELD l_comptype
                     ID 'RSZCOMPID'  FIELD i_compid
                     ID 'ACTVT'      DUMMY.

I wonder if this was a role comparison issue.  The role was not Yellow status, but there are continual problems in this system with user comparison not working (roles staying yellow) after the PFUD job runs.  The only consistent method solution was to use explicit values in the role.... but looking at this code, I wonder why it though i_actvt was initial.   The role has always had activities 03,16 and 22 explicitly stated.

0 Kudos

Hi,

I have faced the same kind of issue on R/3 system while doing the Upgrade.  What we observed in the same situation, the user had assigned with 2 different roles(say, Role A & Role B) with the same required auth. object is present in both roles.  In Role A, that auth Object with restricted values and in Role B, the same auth. object with value "*".  In that case, if the user assigned with both roles user is facing the missing authorization.  When we tried on trial and error by removing the Role B with auth. obj., it is giving missing auth error as there is no required value and when removing Role A its working.  So we conclude that, on the user buffer ifself, the checks are giving priority to extent for the same object with different values from different roles assigned.

I hope this way it can give you some clue for your workaround.

Thanks,

Venkat