Dear all,

Generally we will assign SAP_ALL to user id WF-BATCH for mail communication and background jobs to avoid missing authorizations.

But we have requirement not to use SAP_ALL for WF-BATCH user id,instead use role for the same.

Hence we created role which replaces SAP_ALL profile for communication and background jobs

Added 444 authorization objects manually and tested for ARM,the workflow is working fine with approvers and provisioning in back-end.

I thought to share the document(As attachment) with you all,might be use full if anybody is looking for same requirement.

BR

Baithi

To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Colleen Hebbert

    Hi Baithi

    As a summary, what is the difference between your customer built role and the SAP_ALL profile?

    Is your role a PFCG version of SAP_ALL or do you actually provides some restrictions. Having a quick look, I’m not seeing any for S_TCODE, S_RFC, S_RFC_ADM or S_DEVELOP.

    If you have just built a ZSAP_ALL role the I believe you have missed the point of why you were told not to assign SAP_ALL to WF-BATCH

    Regards

    Colleen

    (0) 
    1. Baithi Srinivas Post author

      Hello Colleen,

      we have not considered all the objects from SAP_ALL,only required authorization objects are added as per our requirement by putting trace.

      S_TCODE, S_RFC, S_RFC_ADM or S_DEVELOP all are added manually and provided field value as *

      BR

      Baithi

      (0) 
      1. Colleen Hebbert

        Hi Baithi

        Do you have examples of which objects you chose to exclude and why you excluded? A trace file is a good start to tell you what it checked but it doesn’t necessary mean you must grant the access.

        444 objects and adding asterisk to the objects I mentioned sounds like too much access for that user. The idea is to limit WF-BATCH to the permissions it needs for its functions (namely workflow)

        The objects I mentioned were just a few quick examples of sensitive authorisations that you would expect to be restricted. As a test, if you are using Access Risk Analysis, have you tried running a risk analysis against the standard rule set to see how many violations the role contains?

        Regards

        Colleen

        (0) 
        1. Baithi Srinivas Post author

          Hello Colleen,

          We have not compared objects with SAP_ALL,created role for ARM workflow only(New Account and Change account) and also tested for the same.

          added the objects as per the error and given field value as * where we don’t want to take risk in further for any missing authorization.

          We have added this role in critical roles and we have not tested in ARA.

          As per my understanding there will be lot of violations to this role.

          BR

          Baithi

          (0) 
          1. Colleen Hebbert

            Hi Baithi

            I can see that you have limited to two specific GRC objects for ARQ. However, I feel that you have too much access in the Basis class objects which is unecessary and a risk.

            If you are running traces for the WF-BATCH user in GRC you should be able to identify a much smaller list of objects.

            Quite a few organisations will give a directive to say no user (including system accounts) are to be assigned SAP_ALL. Security go away and copy SAP_ALL into a role called ZSAP_ALL as a way to follow the policy. End of the day the risk is the same. I can see that you have not done this, but with the non-GRC class objects you do have elevated access in the role.

            Regards

            Colleen

            (0) 
            1. Baithi Srinivas Post author

              Hello Colleen,

              Yes we too agree that,we have given extensive access to some objects due to shortage of time line, which might be not required.

              we have not copied SAP_ALL,infact taken some objects respect to workflow function.

              BR

              Baithi

              (0) 
            2. Raj Kumar Salla

              Hi Colleen,

              Have you identified what minimum authorizations objects be assigned to WF-BATCH so that workflows, background jobs and other actions can be performed effectively without assigning any additional authorization objects that are not required.

              This is certainly a good point you raised and I would be glad to learn 🙂

              Regards

              Raj

              (0) 
              1. Colleen Hebbert

                Hi Raj

                I haven’t built the role (not on a system at the moment). Really, it will come back down to what you are implementing in GRC

                I’d probably put a trace on and test the user to see what comes up. Treat building the access like building any security. The starting point is to define what the user is being used for.

                Regards

                Colleen

                (0) 
    1. Baithi Srinivas Post author

      Hello Alessandro,

      Not exactly compared with role SAP_BC_BMT_WFM_SERV_USER but sure some objects were considered.

      Our goal is for only Access request approvals,may be some additional objects added which are not required for our requirement.

      Regards

      Baithi

      (0) 
        1. Baithi Srinivas Post author

          Hello Prasant,

          Yes,in one of my previous project customer is not accepted for SAP_ALL,hence we have created separate role by taking reference of some objects from role:SAP_BC_BMT_WFM_SERV_USER and put trace by trial and error as per our requirement.

          Regards

          Baithi

          (0) 
          1. Colleen Hebbert

            Hi Baithi, Prasant and Ale

            Just another thing to consider with WF-BATCH that you have two levels of access to consider

            1. core WF-BATCH jobs that have to be run and comms (e.g. restart items in error and so)
            2. GRC specific workflow activities which will depend on what you have implemented

            Trial and error is a large part of it. If time allows, I’d leave SAP_ALL on and run traces through the key scenarios to build from there

            Regards

            Colleen

            (0) 
  2. Priyanka Mathur

    Hi Colleen, Baithi,

    Apart from fixing the authorizations through trace, we also need to assign SAP_GRAC_ALL to WF-BATCH user for MSMP workflows to work. I remember this as a required step from GRC 300. Please correct me if I am wrong.

    Thanks & regards,

    Priyanka

    (0) 
    1. Colleen Hebbert

      Hi Priyanka

      I don’t pay that much attention to SAP standard roles. If you’ve run traces for your scenarios then you’ll have the objects

      They are a good starting point to identify the actual access and then proceed from there.

      Definitely better than SAP_ALL

      Regards

      Colleen

      (0) 

Leave a Reply