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: 

Authorization-check for infotype 0000 (actions)

former_member74904
Contributor
0 Kudos

hi all,

I have always been under the impression that infotype 0000 (actions) cannot and should not be authorized on subtype level.

e.g. certain users are only allowed to execute specific actions belonging to their tasks.

we usually achieve this by restricting the users on usergroup parameter (UGR) so that they only see the actions that are allowed for them in PA40.

Now, it is still possible for users to access and execute actions they are not supposed to do through PA30 --> infotype 0000 and then selecting the subsequent subtype/action.

Master data access is still restricted by the assigned roles so no additional infotype access is granted, however, it is possible for users to execute a firing action where they are not supposed to.

as per note [555154|https://websmp230.sap-ag.de/sap(bD1ubCZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=555154|555154] it states that infotype 0000 does not have subtypes (see also table T582A), yet it is possible to restrict access to these subtypes when I test it.

what is the correct approach in this?

thanks in advance for your input!

6 REPLIES 6

Former Member
0 Kudos

Hi Dimitri,

The suptype for inrotyp 0000 will be the actions that are set up in HR. Infotype 0000 is like a mater infotype. So even if you put a * in it, it will not percolate down as evet relevant infotype will gave its access. Some one having access to infotype 0000 doesent mean he can have access to other infotypes. If you look at your table T582A it will contain the list of actions allowed. But giving them this access dosent mean anything unless they have specific access to them form the concerned infotype.

Hope it helps.

Regards,

Chinmaya

0 Kudos

I realize that by allowing users access to all actions of IT0000, I will not automatically grant them access to all underlying infotypes the different actions initiate. In this regard, there's not really an authorization breach.

However, a user is able to change the employment status (STAT2) of any PERNR he or she is authorized for. This is not something I'd like to see, obviously. The hiring and firing actions are only permitted to be performed by certain users.

0 Kudos

As far as I know all function pertaning to emplyee status Hired/Termination/Retired/Transfer are controlled directly in infotype 0. I suppose you may have to use the authorization level field in P_Orgin as Read only or possibly use Personel Sub Area or some other parameter to restrict this authorization.

I am not aware of anything controling access to this directly. But you could possibly try by putting on a trace and running PA30 and creating/changing infotype 0 with a relevant value and see if there is something you can use.

0 Kudos

Hello,

The access to IT 0000 ( actions ) can be controlled using the Auth. Object P_ORGINCON.

You can provide M, R for IT0000 or * if you want to give the user full access to the IT0000.

However what i feel in your case is that this user is getting access to maintain this infotype from some other roles ( if assigned ).

A better approach to find out the problem could be by using the trace authorisation ( ST01 ).Using this you can find out where the access is coming from.

Try this out and let me know if this helps solve the issue.

0 Kudos

Hello,

I forgot to mention about the auth object P_PERNR.

You can restrict the IT 0000 to be display for the user by using E for the AuthC filed.

Hope this helps..

0 Kudos

hi pramathesh,

we are currently using the combination of P_ORGIN and P_ORGXX without structural authorization to control HR master data access, so there's no need for us to use P_ORGINCON.

you have to understand that restricting write access to infotype 0000 will not solve my issue, because the users concerned still need to be able to execute certain actions (just not all).

in this regard, P_PERNR will also not help because write access to 0000 needs to be maintained.

thanks!

Edited by: Dimitri van Heumen on Feb 26, 2009 12:49 PM