Skip to Content

1. Introduction – the need.

Your company is currently managing emergency access requests manually, based on approved ticket or request in another system or ticketing tool. You would like to enhance the usage of GRC AC tool and enable requesting for emergency access assignment in a way similar to requesting user regular access requests – via SAP GRC Access Request Management system. Your Audit team, however would like to limit number of people who can access this kind of access request, as it is critical from risk perspective.

2. Expected result – emergency access requests.

On the request type drop-down – you would like to see a new request type “Emergency access request”.

/wp-content/uploads/2015/01/1_631047.png

On the request detail (line item level) – you would like to see a new entry “Firefighter ID”.

/wp-content/uploads/2015/01/2_631048.png

Next after ‘Firefighter ID’ entry selection – and you would like to specify validity period for EAM assignment.

/wp-content/uploads/2015/01/3_631076.png

Next you would like FF account owner to approve this access via SAP GRC work-inbox, exactly in the same way as other access requests being approved. You expect one stage approval – being made by EAM account owner.

/wp-content/uploads/2015/01/4_631077.png

3. Enable new access request type for Emergency Access (step by step)

3.1 Activate superuser access request type for SAP GRC 10.

Go to SPRO – > GRC -> Access Control -> User Provisioning -> Define request type

In this Customizing activity, you can maintain the request types, and then assign actions to the request types. SAP delivers several standard request types. These standard request types represent actions that occur in the back end systems.

/wp-content/uploads/2015/01/5_631078.png


/wp-content/uploads/2015/01/6_631079.png

Click on box to activate

/wp-content/uploads/2015/01/7_631080.png

3.2 Select action for superuser request type.

Click on line item for Super User Access and next click on Select Action and ensure you have ‘Super User Access’.

/wp-content/uploads/2015/01/8_631081.png


3.3 Save and transport.


3.4 Validation. On your access request – > if you done everything correctly – you should be able to see new request type with Super User Access request type. Make sure you have appropriate authorization and additional authorization (request type ‘6’ in example case) will be required to see / create this access request as per expected solution requirements.


4. Build path for Super user access assignment request type (step by step)


Now when your new request type is available in the system, you need to make sure you have workflow path in place to handle those request.

4.1 Modification (or creation) of initiator rule

If you already have workflow for access request in place (as mentioned in Introduction) – you need to just update your Initiator rule to handle new request type. To update your current initiator rule – go to ‘BRF+’ transaction code and find your initiator rule (if you do not have it yet – first it need to be create see other documents for information in case you are wondering how to do this like:GRC Request with both System and Role Line Items

or  AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls ).

Next click on Table settings.

/wp-content/uploads/2015/01/9_631082.png

Make sure field ‘REQTYPE’ is on the list of Condition Columns.

Next modify new entry (/wp-content/uploads/2015/01/11_631095.png)in decision table and add new condition by clicking /wp-content/uploads/2015/01/12_631096.png and selecting  Direct Value Input from the list in ‘REQTYPE ”column.

/wp-content/uploads/2015/01/13_631085.png

/wp-content/uploads/2015/01/14_631086.png

In result section enter (in LINE_ITEM_KEY – contex parameter ITEMNUM) and Rule_Result (direct value input for example Z_EAM)

/wp-content/uploads/2015/01/15_631087.png

Next activate your function and transport changes


4.2 Building path for EAM access requests

Enter the transaction code ‘GRFNMW_CONFIGURE_WD’ and open Workflow navigator.

Select process for ‘SAP_GRAC_ACCESS_REQUEST’ and click edit

/wp-content/uploads/2015/01/16_631088.png


4.3 Define result for initiator rule.


Go to Maintain Rules and find your initiator rule.

/wp-content/uploads/2015/01/17_631089.png

and click on ADD button.

Next add your Rule result defined previously – in my case it was Z_EAM.

4.4 Define Path

Define the path name and stage

/wp-content/uploads/2015/01/18_631090.png

Create new path in my case Z_EAM:

/wp-content/uploads/2015/01/19_631091.png

4.5 Maintain Stages


Next you add one stage – there is standard agent available GRAC_SPM_OWNER. Whoever you define as EAM owner will be now approving emergency access requests. 

/wp-content/uploads/2015/01/20_631092.png

4.6 Maintain route mapping


Assign this new created path Z_EAM to result you have from your initiator rule (in my case also Z_EAM)

/wp-content/uploads/2015/01/22_631093.png

4.7 Activate the Workflow version


Last step and you done with your configuration – you can now start to create access control workflows.

/wp-content/uploads/2015/01/23_631094.png

Please share and contribute in this document to make it better.

Looking forward to hear from you.

Best regards,

Filip

To report this post you need to login first.

14 Comments

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

      1. Bhupinder SIngh Arora

        Hi Colleen

         

        Thanks for reply, I have seen that links also, every time I got somewhere lost connection for result which we are setting in BRF+ for rule.

         

        So need bit more details for where are defining result for that rule

         

        Thanks

         

        Bhupinder Singh Arora

        (0) 
        1. Colleen Hebbert

          HI Bhupinder

           

          it might be easier to let us know where you get lost

           

          This document and the others show the link. BRF+ decision table output is the rule result. You make these values up and then reference them in the MSMP for the Initiator rule. The document I wrote on MSMP provides a diagram to show this connection.

           

          Regards

          Colleen

          (0) 
  1. Markus Richter

    Hi Colleen,

    thanks for the great post!

     

    I got a question on section

    4.1 Modification (or creation) of initiator rule:

     

    I would need to get different results based on the EAM ID entered in the Access Request. One might be critical and needs another result.


    But I am not able to get the EAM ID from the request line items in BRF+ in order to have a DBLookUp or so to run over the EAM ID.


    Any idea?


    Thanks and best regards,

    Markus

    (0) 
    1. Filip Nowak Post author

      Hi Markus,

       

      thanks for review for my post:) You can also rank it if you want – just click on stars- below the text.

      Coming to your question – EAM ID – is not available in standard. What I would suggest is to create separate user groups for each EAM ID and next based on user group differentiate your workflow paths,

       

      Filip

      (0) 
      1. Yongbiao Chen

        Hi Filip,

         

        thanks for your great document.

         

         

        regarding getting EAM ID, you suggested to create separate user groups for each EAM ID.

         

        I tried this but from the debug log the user group is only for the user id not the EAM ID. is there any more information how to get user group for EAM ID?

         

        Thanks and best regards

        Yongbiao2015-4-23 10-12-42.jpg

        (0) 
        1. Filip Nowak Post author

          Hi Yongbiao,


          the other way around. First you assign USER ID (1:1 to EAM ID) to USER GROUP, based on user group you differentiate the path (different one).


          Can you share how did you got this advance view for debugging?


          Filip


          (0) 

Leave a Reply