Authorization check flow

[Former Member]

Hello Folks,

I wonder if some one can help clearing a doubt of mine.

The standard definition one finds on the net for Authorization check maintenance in SU24 for transactions is:

CM = Check performed AND object added in PFCG when tcode added to the role.

C = Check performed BUT object not added in PFCG when tcode added to the role.

N = No check OR check will return sy-subrc = 0 even if the user does not have the authorization.

U = Unknown. A check will may be hardcoded in the program, or maybe not.

My take on the above definitions is:

example object: V_VBAK_AAT

if

CM for V_VBAK_AAT the object is included in the role while working with PFCG.

As per the definition check performed on object and object added.

Question 1: Even if the object is maintained as CM it would not make a difference if the check is not coded in the program (authority-check). Would it?

If

C check performed but object not added

Question 2: If a check is going to be made on this object, why not include it in the role i.e mark it as CM? I was once told that these are objects that are most commonly used and hence from a BASIS point of view that the roll buffer will have that much less authorizations to load. But that does not ring true to me.

If

N - check will return value 0 thereby allowing the user through even though he does not have the authorization to do so

Question 3: Why suppress a check that is coded into the prgram in the first place. After all, the whole idea of Security is "any authorization not explicitly assigned" means NO AUTHORIZATION

For the last couple of years that i have been working on this, i have accepted this, as one would, the bible :-)...

But now i wonder if there will be some enlightenment....

Regards,

Prashant

[Former Member]

>

> 
> Question 1: Even if the object is maintained as CM it would not make a difference if the check is not coded in the program (authority-check). Would it?

no, it wouldn't. the check has to be coded.

>

> Question 2:  If a check is going to be made on this object, why not include it in the role i.e mark it as CM?
>

because you would have many obsolete objects in your role, depending on the setup of your applications, the org-structure and several other things (mostly in configuration), whether an extension-set is active, a special IS used ...

>

> Question 3: Why suppress a check that is coded into the prgram in the first place. After all, the whole idea of Security is "any authorization not explicitly assigned" means NO AUTHORIZATION
>

here one can only guess. one scenario might be: due to a bug in a SAP standard BAPI you deactivate the check until you get a correction from SAP. you have to do this to keep up the business ...

Edited by: Mylene Euridice Dorias on Mar 11, 2008 3:59 PM

[jurjen_heeck]

> Question 1: Even if the object is maintained as CM it would not make a difference if the check is not coded in the program (authority-check). Would it?

It needs to be coded in the program. In SU24 you cannot add checks and expect them to be performed.

> Question 2: If a check is going to be made on this object, why not include it in the role i.e mark it as CM? I was once told that these are objects that are most commonly used and hence from a BASIS point of view that the roll buffer will have that much less authorizations to load. But that does not ring true to me.

Sometimes it isn't true but that's why you can adjust SU24 to fit your needs.

> Question 3: Why suppress a check that is coded into the prgram in the first place. After all, the whole idea of Security is "any authorization not explicitly assigned" means NO AUTHORIZATION

Because the check may shield information that is not valuable in your situation? Checks are built in to suit the needs of as many customers as possible but in a lot of situations they're considered overkill.

[Former Member]

Thanks Folks, that does help

Prashant

[Former Member]

Hi Prashant,

This thread is very informative. Thank you for this

I just had one more thing to add:

SAP has allowed only 'check' or 'check/maintain' for Basis auth. objects

So I guess SAP has ensured security for basis objects, regarding concerns for suppressing checks ('N') 😛

Guru's, Please correct me if anyone feels I have lost it

Thank you

Abhishek

[jurjen_heeck]

>

> I just had one more thing to add:
> SAP has allowed only 'check' or 'check/maintain' for Basis auth. objects
> 
> So I guess SAP has ensured security for basis objects, regarding concerns for suppressing checks ('N') 

Is correct, but not only basis. In HR some checks also cannot be disabled and there are some others as far as I know.

I guess SAP's product integrity/reputation would be at stake if you were allowed do kill the whole authorization mechanism with a few mouseclicks.

[Former Member]

Well said Jurjen!

Thanks for sharing the info on HR objects too

[Former Member]

Thanks Abishek, Jurgen