Query Authorizatoin-Check

[Former Member]

Hi,

I am having one query regarding Authorization Objects. lets say following is the authorization check statement-

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD pernr-abkrs
    ID 'ACTVT' FIELD '02'.

can someone tell these two fields 'ABKRS' and 'ACTVT' will act as 'AND' or 'OR'.

And how can we put 'AND' / 'OR' on two fields of authorization Object.

Thanks & Regards,

[Former Member]

try this link

http://help.sap.com/saphelp_nw04/helpdata/EN/52/6712ac439b11d1896f0000e8322d00/content.htm

[Former Member]

This authorization field acts based on the value in the field ABKRS. The activity specifies what kind of activity is allowed on the transaction involving ABKRS.

01 - Create

02 - Change

03 - display

04 - delete

If you want to add any other fields in addition to the ABKRS, you have to check for the authorization object which suits your requirement in SU21. It is not possible to manually add using AND/OR.

If none of them suit your requirement, you can request the Security team to create a new authorization object for your requirement.

Thanks,

Janani

[Former Member]

Hi,

To answer your questions, the values act as AND logic, your role needs to contain both values. If you want you check with OR logic you can call the check twice, once with each field.

e.g

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ACTVT' FIELD '02'.
lv_subrc_1 = sy-subrc.

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD pernr-abkrs.
lv_subrc_2 = sy-subrc.

Then check the values of lv_subrc_1 and lv_subrc_2 to see if either check passed.

Regards,

Nick

[Former Member]

Thanks for prompt responses, But my only query was if i am using authorization object as below mentioned syntax:

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD pernr-abkrs
    ID 'ACTVT' FIELD '02'.

Lets say we have given authorization for to user for ABKRS' = 04 and 'ACTVT' = '02' .

Case 1.

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD '04'
    ID 'ACTVT' FIELD '02'.

Sy-subrc is coming as ZERO (True )

Case 2.

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD '04'
    ID 'ACTVT' FIELD '03'.

Sy-subrc is coming as ZERO (True )

Case 3.

AUTHORITY-CHECK OBJECT 'P_PCR'
    ID 'ABKRS' FIELD '05'
    ID 'ACTVT' FIELD '03'.

Sy-subrc is coming as 4 (False )

I am feeling like its only checking 'ABKRS' or OR condition is implied b/w two fields.

[Former Member]

Hi,

I the situation you describe, Case 2 should not give you return code 0. Is it possible that the user has this object assigned to multiple roles? The authorisation check will combine the values in all roles and check against this. The easiest way to check is after you run case 3 (which sets RC 4) run transaction SU53, this will list al values available to the user for this object.

Regards,

Nick

[Former Member]

I understand that the thread is answered, but wanted to add a little comment:

>

> I the situation you describe, Case 2 should not give you return code 0.  
> 

This is very subtle but important.

Some folks build applications and roles in such a way that you can change what you also prior could display, if you are authorized to change "something". Personally I agree with this check on display of the item to be changed, but not the consequences of it "in the wild" when the ACTVT '02' authority check then does not check other field ID's subsequently or uses a DUMMY construct for them.

To combat this (and the "OR" argument which is wanted here) some applications use a "base-check" form, which is performed (consistently) within the application regardless of the navigation of the user, going back and forth and F4 etc.

This way the user always has the same experience (and messages) in the application, regardless of the navigation (and Tcode...) and roles can be built using instances of the authorization objects using all fields.

This way, you always get what you design in one instance of an authorization, whether you define it in SU24 or add it manually or what ever...

Where this approach does create confusion is here:

> The easiest way to check is after you run case 3 (which sets RC 4) run transaction SU53, this will list al values available to the user for this object.

SU53 gives the last failed authority-check per object immediately prior to executing SU53. Sometimes dropping an Su53 shortcut into a popup helps, but it is not debugging.

This means that in an authority-check contruct such as the example given by Nick, your SU53 result might not be the correct one in the "OR" argument.

Possibly the first check is the control you wanted. Possibly it failed and the second one passed, and causes misleading information for the next transaction which has faulty config and an authorizations is assumed to be the problem.

Cheers,

Julius

[Former Member]

Thanks Nick, for very usefull answer.