Skip to Content

ESS security setup – P_PERNR for own records and P_ORGIN impact on HR access

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

ESS incorrect.png

Qualification Reporting

Qual report incorrect.png

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

ESS correct.png

Qualification Reporting

Qual report correct.png

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
You must be Logged on to comment or reply to a post.
  • Excellent and concise description of a common HCM issue. Along with its solution. Thanks for sharing this, I'm sure it will be of great use to many people.

  • Hi Karsten,

    Nice blog! I liked the usage of easy language to explain the concept.

    However, I would beg to differ on the following explanation:

    . The authorisation check will look at this as follows: 

    “Oh hello, do you have P_ORGIN with read access. Yes you do, but, what infotype is that for?
    OK I check P_PERNR in the same role for further specification. And there I find you can read 0007, 0008, 0188, 2001 and 2002 for yourself.”

    The P_ORGIN will not cross pollinate any longer as it cannot grant authorisation by itself. The P_PERNR object will only ever be interpreted with the P_ORGIN object in the same role, due to this specific setup of P_ORGIN.

    Per SAP documentation in help.sap.com and my experience, P_PERNR object is checked prior to P_ORGIN and P_PERNR authorisation can directly override any other authorization check (except test procedures).

    Hence in your example P_ORGIN node of ESS role is superflous since you have aleady provided access to user's own data via P_PERNR.

    You might want to refer to the following topic on help.sap.com

    http://help.sap.com/erp2005_ehp_05/helpdata/EN/1e/07a984ebb14f4a978c4993cae7c3e1/content.htm

    Thanks

    Sandipan

    • Thank you Sandipan,

      of course you are right. P_ORGIN is not required at all in an ESS authorisation setup. I have updated my blog with this information.

      The reason that I left the P_ORGIN object in my ESS role without any infotype and subtype is only to visualise, that the object doesn't grant any access. I think it might help some of our colleagues to set up P_ORGIN without values rather than taking it out completely as this emphasises in a simple way that no access is granted.

      I further took your advice and corrected the description about the flow of the authorisation check. As you said correctly, P_PERNR is checked first and P_ORGIN subsequently.

      Kind regards

      Karsten

      • Many applications integrate with HR, so it might be usefull to have the matchcode AUTHC on very basic infotypes such as 0001 used by searches into the ESS role or even common role for all users.

        Another trick:  I see that you build your authorizations manually. You can double-click the text description of the authorization instance and change the default text of the object name to any text of your own. This gives admins some info without having to read infos on a server somewhere...  🙂

        Note: For Standard auths which can be merged, the text is always defaulted to the object text! So only use it for Manual and Changes auths!

        Shame on me for mentioning this actually, but in HR the roles are more data dependent than reusable tcode proposals to close many fields, so in a moment of weakness I thought I would contribute a bit out of character....  🙂

        Cheers,

        Julius

  • hi all

    what if we have to give in a role infotype 2001 to be restricted in R/3 not to maintain their own data 'E',  but all ESS users have 'I'

    For example Time Administrator is assigning Absences quotas to the users in R/3. but he should not be able to assign quotas for his own user.

    but in ESS he should be able to apply for his own absence's which required I for infortype 2001

    Cheers

    Irufan

  • Thank you so much for sharing this! I've been looking high and low for solution to this problem...and you have illustrated wonderfully! Excellent post!