Restricting ESS role to view only own data

[Former Member]

Hi,

I was trying to understand the way ESS role works in ERP. I created a role with P_PERNR auth object and allowed it access to several Infotypes like address 0006 and allowed it to have Interpretation to be "E" and assigned it to my user id. I thought if I run a simple report which basically looks up data like address, I will not be able to view my own data but can see other's addresses. But that did not happen, I could see everyone's addresses including mine. Is my understanding of P_PERNR correct ? Do I need any more auth objects to get the desired result ? How do I go about restricting access for a user so that user can see only his data and not others and other way as well where user sees other people's data but not his ?

Based on documentation it sounded simple enough to use only P_PERNR, but may be I am missing something very basic.

Please help me understand the basic concept.

Thanks,

SV

[Former Member]

Hi,

Your understanding is correct! P_PERNR with PSIGN as I will give access to data stored under employee's own personnel number and E will restrict the same access. But data for all other Personnel numbers will work as per P_ORGIN and you cannot restrict a user to access only his own data through P_PERNR if P_ORGIN object is included in the role with same infotype/authorization level values.

In your case, seems like P_PERNR is not working as expected. Can you check in table T77S0/tcode OOAC if the switch AUTSW PERNR = 1 ? That's what activates the restriction based on object P_PERNR.

Also, for P_PERNR to function, your user ID has to be assigned with a personnel number i.e a valid IT0105 (subtype 0001) relationship must exist.

Thanks

Sandipan

[Former Member]

Hi Sandipan,

Thanks for your reply.

The switch for P_PERNR = 1 in table T77S0. But the P_ORGIN is not activated in our system as the table T77S0 has

AUTSW ORGIN = 0. It would be nice to know if I can really restrict the user and how without P_ORGIN.

Thanks,

SV

[Former Member]

Hi,

Since P_ORGIN is not activated in your system, the user either would have or would not have access to data under thier own personnel number only based on values of field PSIGN in object P_PERNR.

For all other personnel numbers P_ORGIN(CON) is required. So in case you want users to access data under other personnel number except his own, check for P_ORGIN (or P_ORGINCON in case if context based structural authorization) has to be activated.

In your case P_PERNR is not working as expected at the first place( according to your earlier post) when you tried testing with your user id. Can you check if the user id you used is attached to a valid personnel number via IT0105 subtyp 0001? Because without that, P_PERNR check won't work as expected.

Thanks

Sandipan

[Former Member]

Hi Sandipan,

My id had a valid IT0105 record with all the basic subtypes defined in the system. But still it did not work.

In our system, we have AUTSW ORGPD =1.

Hi,

Since P_ORGIN is not activated in your system, the user either would have or would not have access to data under thier own personnel number only based on values of field PSIGN in object P_PERNR.

For all other personnel numbers P_ORGIN(CON) is required. So in case you want users to access data under other personnel number except his own, check for P_ORGIN (or P_ORGINCON in case if context based structural authorization) has to be activated.

In your case P_PERNR is not working as expected at the first place( according to your earlier post) when you tried testing with your user id. Can you check if the user id you used is attached to a valid personnel number via IT0105 subtyp 0001? Because without that, P_PERNR check won't work as expected.

Thanks

Sandipan

[Former Member]

Can you also verify if your id has access to PSIGN=* in object P_PERNR from any role assigned to your id?

Please note value '*' is equivalent to value 'I' and it overrides value

'E' i.e you get access for infotypes maintained under your own personnel number.

[Former Member]

Hi Sandipan,

Can you also verify if your id has access to PSIGN=* in object P_PERNR from any role assigned to your id?

Please note value '*' is equivalent to value 'I' and it overrides value

'E' i.e you get access for infotypes maintained under your own personnel number.

[Former Member]

Hi Sandipan,

Sorry for earlier post. I have 'I" instead of "*" in PSOGN in object P_PERNR.

Thanks,

Sonali

[Former Member]

Sonali wrote:

I have 'I" instead of "*" in PSOGN in object P_PERNR.

Well then P_PERNR is working as expected, PSIGN=I will show you data stored under your personnel number.

However, your first post on this thread said:

 I created a role with P_PERNR auth object and allowed it access to several Infotypes like address 0006 and allowed it to have Interpretation to be "E" and assigned it to my user id. I thought if I run a simple report which basically looks up data like address, I will not be able to view my own data but can see other's addresses. But that did not happen, I could see everyone's addresses including mine

So you don't really have PSIGN= E in roles assigned to your user ID. Am I right?

[Former Member]

Hi Sandipan,

May be I should have been more clear. I first created a role with P_PERNR auth object and allowed it access to several Infotypes like address 0006 and allowed it to have Interpretation to be "I" first and tried to access my own data and other user's data and It worked. Then I thought if I cahnge PSIGN to be "E", may be I can view only others data, but I can view everone's data. And so got confused as having PSIGN to have "I" or "E" , is really not making any difference. I can view everyone's data

no matter what. In both the cases my ID had Infotype 105 entry.

Hence my question.

Thanks,

SV

[Former Member]

Then I thought if I cahnge PSIGN to be "E", may be I can view only others data, but I can view everone's data.

If its the same role in which you changed the PSIGN value (I suspect you did that instantaneously during testing) from I to E, did you run user comparison on that role or reset the buffer of your user id with SU56 or by simply logging off and logging back again?

Can you please double check? There is a possibility that user's buffer still contained the value PSIGN=I when you were expecting it to exclude your personnel number.

Thanks

Sandipan

[Former Member]

Hi Sandipan,

I did perform the tests again and found that the P_PERNR works as it should be with SAP standard code. If I use custom code

then it does not and I was using the custom code all along. At least my understanding of the P_PERNR is now clear. Thanks for all your help and guidance on this.

Thanks,

SV

[Former Member]

Thanks for confirming:) I suspect your custom code doesnot has any authority check defined for P_PERNR or even if it does the logic has used the values of P_PERNR incorrectly.

My 2 cents

Sandipan

[Former Member]

You have now duplicate posted the same issue...

Please add the infos about the webservices to this thread, and then I will "quaranteen" the other one(s).

It should be clear to you that you are wasting also your own time and ours by not asking a detailed question...

Please also read the forum rules at the top of the forum overview page.

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your reply and feedback. So here is real question and I will make sure to ask the detailed question next time the first time.

In our HR system, we mostly used standard SAP transactions and had no issues with data security. But recently we implemented Web services and custom function modules. Unfortunately there is no authorization object being checked when the function modules were written by developers. Hence we found out that the users can access the data that they should not.

What is the best approach in this case ? Should we ask the developers to perform authorization checks in their code and rewrite all the code ? Is there any way as security admins we can still restrict the access to the data even if the developers do not check the authorization object in their code ?

Some of the code is already in Production and your answer will be very helpful.

Thanks,

Sonali