Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

I contemplated writing this blog for quite a while and have delayed it for some time, because it is not a new issue and it is basic HR security. However, I have seen many SAP clients struggling to get that basic setup right. So, why not blog about it? It might help some of you.

We all know that authorisation object P_ORGIN is used to limit access to infotypes and related activities, don’t we?

We also know that authorisation object P_PERNR gives us an opportunity to restrict users to either their own records or to everyone else’s record, don’t we?

That was easy.

Now we might encounter an issue. Imagine an employee needs ESS access and within that lots of infotypes like 0007, 0008, 0188, 2001 or 2002. Alright, we restrict P_ORGIN to display these infotypes and we set P_PERNR to restrict the ESS access to the employee's own record only.

Suddenly, we find that our new ESS user also needs another SAP backend authorisation to display infotype 0024 (qualifications) in combination with transaction PA20. But this is not where our requirement ends. Just imagine that the ESS user doing the qualification reporting must also check the basic pay. As we all know highly skilled people should earn higher salaries. That is why our ESS user will get infotype 0008 (basic pay) display access as well.  The access for infotype 0008 is restricted to certain employee subgroups, so that our user cannot display the basic pay records of the company’s executives.

Now we face the issue of cross pollination. The ESS role contains P_ORGIN with infotypes 0007, 0008, 0188, 2001 or 2002 and no further restrictions. The qualification role restricts infotype 0008 access through P_ORGIN to certain employee subgroups. The dilemma is that P_ORGIN assigned through the ESS role would override the restriction for the employee subgroup of infotype 0008 enforced by the qualification reporting role.

Here is an example how the setup is done WRONGLY. Sadly, I have seen it at many sites like that.

ESS

Qualification Reporting

The setup shown above won’t work. The restriction on infotype 0008 of the qualification report role is resolved by the P_ORGIN in the ESS role. And the P_PERNR of the qualification report role will override the ESS restriction. As result the ESS employee with qualification report access can happily report on anyone’s pay without restriction.

Surely there must be a way to resolve that.  Logic tells us that we need to find a way to give everyone access through ESS without creating a generic infotype access which would then cross pollinate all other roles.

Here is how it works:

ESS

Qualification Reporting

Why does that work?

Looking at the ESS role first, we find that the P_ORGIN object has neither an infotype specification nor a subtype specification and will therefore not grant any access if it is considered without the context of P_PERNR. That means in other words, we could go further and completely remove P_ORGIN from the ESS role as it doesn't grant any access at all.  The authorisation check will look at this as follows:

“Ok let's see what are you allowed to see? First I like to know if you have permissions through P_PERNR. There you go, you have permission to see your own data for infotypes 0007, 0008, 0188, 2001 and 2002.

Now lets see if you have permissions through P_ORGIN to further HR groupings. No you don't but anyway, that is all right, as you only request display access to your own data through ESS”

The P_ORGIN will not cross pollinate any longer as it cannot grant authorisation by itself. The P_PERNR object will grant access to the employee's own records which is absolutely sufficient for ESS. It doesn't matter that the subsequent check for P_ORGIN fails.

Now, that means for the Qualification Report role that the P_PERNR object of the ESS role will no longer restrict the infotype 0008 access to the employee’s own basic pay record.  Therefore it is no longer required to have the P_PERNR object (overriding setup with '*' in field PSIGN) in the qualification role. The access to infotype 0008 is now restricted correctly through the employee subgroup restrictions of P_ORGIN in the Qualification Report role.

Everyone will be happy.

7 Comments