The purpose of this post is to demonstrate how to create Template Based Requests and make them available for provisioning in SAP. This document will demonstrate how to customize and associate End User Personalization forms for use with Access Request: Template Based Requests.

 

    Template Based Requests are an effective way to provision access in SAP environments. Security administrators can create pre-defined templates with specified roles for each back-end environment to simply provision requests for end users. In addition, templates can leverage the Business Role Concept from Business Role Management in GRC 10.0/10.1 to provision bundled composites and singles roles across multiple back-end environments. The following steps outline the process to follow when implementing template based requests:

 

Step 1: Customize EUP personalization

 

Access the GRC IMG via t_code SPRO followed by menu path:


Governance, Risk and Compliance> Access Control> User Provisioning> Maintain End User Personalization


1.jpg


2.jpg


Step 2: Create copy of the default EUP personalization form

 

Within the IMG activity, select the default EUP personalization form.

3.jpg

 

With the default EUP personalization form selected press F6 or click the “copy as” icon.

 

4.jpg

 

 

Enter a new EUP ID #, EUP Config Name, and Description.

 

5.jpg

 

Execute or hit enter and copy all dependent entries in the following pop-up.

6.jpg

7.jpg

 

 

Click through the confirmation pop-up and save.

 

8.jpg

 

 

Step 3: Customize the EUP Copy

 

Select the new EUP personalization form and double click the maintain EUP fields folder.

 

9.jpg

 

10.jpg

 

Select fields to include or exclude in the Template Based Request and save.

8.jpg

11.jpg

 

List of available options for each field.

 

      12.jpg13.jpg14.jpg15.jpg

 

Step 4: Create an Access Request: Template Based Request and how to associate EUP Personalization forms.

 

Navigate to the Access Management Work center in NWBC and select the Template Management under Access Request Administration.

 

16.jpg

 

Select create, input name of Template, EUP form, and Request Type.

 

17.jpg

 

18.jpg

 

19.jpg

 

Select Access Details, and click the add button, choose role.

 

20.jpg

 

 

Choose single, composite, or business role, move role down and select OK.

 

21.jpg

 

22.jpg

 

Role will now appear in the Template, select save.

 

23.jpg

 

24.jpg

 

 

Access Request: Template Based Request is now available for provisioning.

 

25.jpg

 

 

Access Request: Template Based Request end user view.

 

26.jpg

 

 

Template Based Access Requests can take some time to configure, but the benefits gained simplifying access requests for end users often makes this an easy enhancement to justify for your GRC environment.

In this article, I will provide an overview of the Emergency Access Management reports and which information can be seen. GRC provides six reports specifically for EAM, e.g. the consolidate log report shows firefighting activities which have been executed while using firefighter. The consolidate log report is far the best and used for management review from the firefighter controller (if workflow is in place). The consolidated log report has all the captured information from the backend system in a consolidated view. Following a short overview of the captured information and where it comes from.

 

Transaction Log

Captures transaction executions from transaction STAD. System, Firefighter, Firefighter ID, Reason Code, Transaction, Date and Owner are read.

 

System Log

Captures debug and replace information from transaction SM21.

 

Change Log

Captures change log from change document objects which are stored in table CDPOS and CDHDR.

 

Security Audit Log

Captures security audit log from transaction SM20.

 

OS Command Log

Captures changes to OS commands from transaction SM49. For further investigation or to get more information about the activities performed in the backend system these transactions might be helpful.

 

Other reports are:

Invalid Superuser Report - shows expired, locked and deleted firefighter IDs.

Firefighter Log Summary - shows firefighter ID session details (only available for ID-Based firefighter, see also my blog post about Types of Firefighter).

Reason Code and Activity Report - shows reason and activity details.

SOD Conflict Report for Firefighter IDs - shows SoD conflicts (risk analysis) for firefighting sessions.

 

Please contribute in this blog post and share your experience and know-how about firefighter reporting.

Purpose and functionality

  1. EAM allow users to take responsibility for task outside of their normal job function.
  2. Allow temporary access for users when assigned with solving problem, giving them provisionally broad, but regulated access.
  3. This temporary access will monitored and reviewed by the application.
  4. EAM provides the ability  to manage and utilize firefighting activities centrally from the access control application
  5. The log files can be distributed to controller and owner via workflow for additional approval


Defining Users


  1. The owner of the ID
  2. The controller
  3. The users who will log on through EAM.


Important Roles and Terms


  1. Firefighter:  a business users requiring emergency access.
  2. Firefighter ID:
  3. A user id with elevated priviledges.
  4. Access T-code  GRAC_SPM
  5. Firefighting: the act of using a firefighter id.
  6. Controller:  review and approves (if necessary) the log file generated by the firefighter.
  7. Owner: a user responsible for the firefighter id and assignment the controller of the firefighter.

Firefighter Application type:


There are two deferent applications that can be used that can be used:

  1. ID based firefighter Application
  2. Role Based firefighter Application.
  • Configure in the IMG using parameter 4000 (Application type)
  • Only once application can be configured at a given time. 


GRC Server package

  1. The main application runs in the GRC server.
  2. It is possible to assignment user for all system using NWBC or portal.
  3. Provisioning of the emergency access can also be done via access request(Workflow)


Process


  1. Firefighter access is done centrally using the GRC system.
  2. Firefighter logon to the GUI back and execute t-code GRAC_SPM
  3. Click on the login.


Emergency Access Architecture


Plug-in

  1. Once component called plug-in that is installed in remote system.
  2. Emergency Access Management access the plug-in  using RFC.

Prerequisite

  1. Create users and roles as needed
  2. Execute program GRAC_ROLEREP_USER_SYNC

Centralized firefighter overview and prerequisites

Centralized firefighter overview

  1. EAM provides a centralized console through which firefighter can logon to deferent system for firefighting.
  2. In id based scenarios, firefighter do not have to logon to individual client system to do firefighting.


Centralized firefighter prerequisites

  1. Application type is 1 for id based firefighting
  2. Set parameter group 6 super users management
  3. Set parameter id 4000
  4. Firefighter user must exists in the central access control system and the role SAP_GRAC_SPM_FIREFIGHTER


Centralized Logon Pad


       ● Access Control provides centralized logon pad for accessing the firefighter IDs in all connected back end systems

The centralized logon pad allows:

 

  1. Displaying all firefighter IDs assigned to the user
  2. Logging on to all connected back end systems
  3. Sending messages to other firefighters who are using a specific firefighter ID
  4. Unlocking a firefighter session not closed properly

 

While a Firefighter Session is running

 

  1. The status of the firefighter ID will display in red
  2. The firefighter can take the following actions:

    ● Click Additional Activity to enter more information

    ● If the firefighter ID is in use by another firefighter, choose Message to send notification to the other firefighter

 

● Choose Unlock to unlock the firefighter ID if it is locked

 

EAM Configuration

Parameter setting

4000-Application type

4001-Default Firefighter Validity Period (Days)

4002-Send Email Immediately

4003-Retrieve Change Log

4004-Retrieve System log

4005-Retrieve Audit log

4006-Retrieve OS Command log

4007-Send Log Report Execution Notification Immediately

4008-Send FirefightId Login Notification

4009-Log Report Execution Notification

4010-Firefighter ID role name


Monitoring Emergency Access

 

Firefighter Report types and purpose

Using firefighter reports

  1. Resulting change log is stored in CDHDR and CDPOS tables
  2. Log data is retrieved from the client system and stored in GRC for report generation


Hi,

 

In  GRC10 – ARM  Access Request approver have the choice to do Risk analysis at “Action Level”, “Permission Level”, “Critical Action”, “Critical Permission” and “Critical Role/Profile”.  But In 5.3, Approver didn't have choice to decide while using from CUP.

 

When approver open access request in AC10 under Risk Violation tab Permission Level is always selected .Selection is fine as this is configured this way (Parameter in SPRO 1023 -Default Report Type for Risk Analysis).  But the approver also has an option to deselect "Permission Level".

 

If you want to ensure that approver always keep "Permission Level" as an option, in other words option should be grayed out with permanent tick mark. This is to make sure that CUP enforce "Permission Level" check, otherwise if approver deselect then they can always skip the risk analysis by clicking different report types. Also possibility at times all the approver doesn't understand the meaning of each option.  Both accidental / intentional ways skipping Risk Analysis is possible.

 

As you can see Permission level is always selected but editable. Approver can deselect and submit the request with no violation. This way unmitigated risks can be submitted.


1.png


We have achieved this by deploying SAP NOTE 1796838 - UAM Risk analysis at permission level set to non editable and following below steps.

 

 

1. Go to transaction se80.

Select Package as ‘GRAC_ACCESS_REQUEST’.

Click on Web Dynpro -> Web Dynpro Application

 

2.png


2  .Drill down to application ‘GRAC_OIF_REQUEST_APPROVAL’. Right click on it and click Test.


3.png


3. Now, the following screen will appear.


4.png

 

Go to the URL of the above screen and add the following string to it.


Go to Transaction  SE16 and Enter table name as GRACREQ, enter any request number in REQ_ID field.

Click execute button and copy the value of field REQ_ID

 

Below is String to add in URL-

 

&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/<REQ_ID  checked from above step>

 

Below is example for string to add in above screen dump URL..

&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/984BE163CDB81EE2B79233F7361518D9

 

5.png

Observe that the dump will now get removed and an access request will be opened.


4. Go to the Risk Violation Tab and right click on the Type check boxes and choose ‘Settings for Current Configuration’

 

6.png


5. Now, the following pop up window will appear.


7.png

 

In this, you can go to each of the type of result options and click on ‘read only access’ check box.

 

8.png


6 For example, If you click on Permission Level and set Read-Only Access as ‘Yes’, permission level will appear as non editable on approval screens for all requests.


9.png


Click on ‘Save and Close’.

Please see that the Permission level check box is now disabled.

 

10.png

 

Hope this will help you if you meet such a kind of requirement. and prevent from submit unmitigated Risk.

 

Regards

Dilip Jaiswal.

GRC - IDM Consultant.

Use

In this Customizing activity, you can configure the LaunchPad settings for Governance, Risk, and Compliance (GRC) application menu items. The GRC application uses one repository and seven LaunchPads, one for each work center, as listed below:


Repository

  • Role = GRCIAREPOS
    Instance = GRC_AC_PC_RM_IA_REPOSITORY
    Operation = GRC AC PC RM IA Repository

  Work Centers 

  • My Home
    Role = GRCHOME
    Instance = GRC_SUITE_HOME
    Operation = GRC Suite Home Workset
  • Master Data
    Role = GRCMASDAT
    Instance = GRC_SUITE_MASTER_DATA
    Operation = GRC Suite Master Data IA
  • Rule Setup
    Role = GRCRULESET
    Instance = GRC_SUITE_RULE_SETUP
    Operation = GRC Suite Rule Setup Workset
  • Assessment
    Role = GRCASSESSM
    Instance = GRC_SUITE_ASSESSMENTS
    Operation = GRC Suite Assessment Workset
  • Access Management
    Role = GRCACCMGMT
    Instance = GRC_SUITE_ACCESS_MANAGEMENT
    Operation = GRC Suite Access Management Workset
  • Reports and Analytics
    Role = GRCREPORTS
    Instance = GRC_SUITE_REPORTS
    Operation = GRC Suite Reports Workset
  • Application Administration
    Role = GRCAPPADMI
    Instance = GRC_SUITE_APP_ADMINISTRATION
    Operation = GRC Suite App Administration

 

Note  If SAP provides updates to the content, then such changes update the standard SAP delivered repository and LaunchPads; the changes do not directly update any customized versions.  To view the changes to the SAP delivered versions and to update your customized version go to Extra->Show SAP Version.


Requirements

You have created the new menu item using the Customizing activity Maintain Authorizations for Application Links.


Activities

To create new menu items, do the following:

1. Choose a component for the menu items.

2. Choose New Application.

3. In the field Link Text , enter the menu item name.

4. Select Application Categoryand choose WDA Webdynpro ABAP.

5. In the field Namespace, enter the required SAP namespace.

6. Enter the applications. (This can possibly result in the need for development of the new applications.)

7. Enter the System Alias based on the component of the menu item. You can use the following aliases:

    

    • SAP-GRC for items applicable to both Process Control and Risk Management, and for all (Access Control, Process Control, Risk Management)
    • SAP-GRC-AC for Access Control only
    • SAP-GRC-PC for Process Control only
    • SAP-GRC-RM for Risk Management only


8. Enter the required Application Parameters.

9. In the field Add Information, enter MENUITEMID=<The MENUITEMID,as maintained using the Customizing activity Maintain Authorizations for Application Links.

10. Save your entries.



To link the menu items to a particular LaunchPad, do the following:


1. Double-click the LaunchPad you want to link, for example Master Data.

2. Navigate to the folder to locate the new menu item.

3. Choose Link to a Repository Application.

4. Choose the repository GRC AC PC RM IA Repository, and drag the menu items to the folder.

5. Save your entries.


To create new menu folders, do the following:


1. Double-click the LaunchPad of the work centers in which you want to locate the menu folders.

2. Choose the New Folder pushbutton.

3. Enter the folder name and folder description.

4. Change the icon of the folder. (This step is optional)

Use

In this Customizing activity, you maintain menu authorization of all Governance, Risk, and Compliance (GRC) applications. The autorizations are then used in SAP NetWeaver Portal (portal) or in the NetWever Business Client (NWBC).

Menu items represent individual navigation links. The text is used for reference and to provide an indication about the purpose of the application. Each menu item must belong to at least one or more of the application components listed below:

  • FN, which is the common component used for all GRC
  • Process Control (PC)
  • Risk Management (RM)
  • Access Control (AC)

The application displays the group items and menu items in accordance with the authorizations granted by the user role.  For example, if the user role is not authorized to view any objects and entities in a group, the application will also not display the related menu item.


Note: If you are upgrading from Process Control 3.0, you can use the delivered BC Set for this Customizing activity. For more information, see the SAP GRC Process Control  10.0 Upgrade Guide.


Requirements

You have maintained each menu item ID in Web Dynpro  and in Launchpad Customizing.


Activities

To customize the authorizations, perform the following steps:

   1. Choose the New Entries pushbutton and enter a menu item ID. This is the referenced text for the application item.

   2. Choose the required Authorization Mode from the following:

   3. Choose the Entity Evaluation. You can specify if the item can be enabled by providing authorization only for one entity or object, or if it is necessary to provide authorization for all entities and objects. If no entity or object is defined for the item, then the item is always displayed.

   4. Choose the Authorization Class.

   5. Choose the Logical Operation to provide  an additional authorization check.

You can use an exit class for the ABAP code-based authorization check for a menu item. To do this, follow the requirements listed below:

 

  • Use the interface IF_GRFN_MENU_ITEM_AUTH.
  • The interface contains the method IS_AUTHORIZED. The method has the following  parameters:


Importing Parameters

    • IO_SESSION type, referring to class CL_GRFN_API_SESSION
    • IV_REGULATION of type GRFN_REGULATION
    • IS_ITEM of type GRFN_S_API_MENU_ITEM
    • IT_ITEM_APP_COMP

  Exporting Parameters 

    • EV_AUTHORIZED of type GRFN_BOOLEAN.

 

  The results from the exit class can be combined with the entity-level and if required with PFCG authorization by specifying the type of operation (NO, AND, OR). You can make the required selection and save your data.

   6. If you want the authorization to be evaluated by all regulations, then select the Regulation Relevence checkbox.   That is if one of the regulations is authorized, the menu item is shown.

   7. Choose Used in Application Components.

   8. Choose the New Entries pushbuttonand select the menu items that you created.

   9. Select one of the application components used in the application. In field Application Component, select whether you want to customize the entire GRC, or select the required components from the following: PC, RM, and AC.

  10. If the authorization for the application is evaluated by Entity-Level Authorization or Entity-Level and PFCG Authorization, then do the following:

a) Choose Authorized Entities.

b) Choose the New Entries pushbutton and select one of the menu items you created.

c) Select an entity from the dropdown list to be used with the selected menu item.

d) Save your entry.

Proceed in the same manner with all other menu items.


Eskom Configuration: Not used

SPRO Location

4.png

 

Use

This organizational activity describes how you can activate or modify the delivered Business Configuration (BC) sets.

SAP provides a set of recommended BC sets as a baseline. For example, there exists a BC set for the frequency timeframes, where you define and maintain the time period of your system


Activities

To activate BC sets:


1. To see the activities that have a BC set, choose Existing BC Sets.
The system displays the BC sets on the right hand side of each activity.


2. Place the cursor on a BC set and choose Additional Information ->BC Sets ->Display BC Sets for Activity. The Business Configuration Sets: Display screen appears.


3. To highlight the individual BC set, choose Goto ->Activation Transaction.
The Business Configuration Sets: Activation screen appears.


Note: You must activate each BC Set separately.


4. Choose Activate BC Set or press F7.
The BC Set is activated.

 

Eskom Configuration:  The above does not work.

 

Note: BC Sets activate the default contents on the Configuration Tables


  These BC sets can be activated via transaction code SCPR20

5.png

6.png

Select each of the BC Set ID as per the table below:

7.png


8.png

Use

In this Customizing activity, you establish the settings for transporting the organizational objects created during the set-up of your organizational structure.

This setting suppresses the SAPGUI error and warning messages received from the HR Organization objects as a result of the changes performed, for example, by changing the name of a control in the Process Control application. Examples of objects include risks, controls, processes, and so on. If you do not configure this setting, then there is a possibility system dump appears on the user interface.

Note: You must specify the transport settings for the objects in the organizational plan created for Organizational Management. This is esential because the tool used for the organizational structure set-up in Risk Management (RM) and Process Control (PC) is the same as that for setting up the organizational plan in the clien system.

Standard settings

In the standard system, the automatic transport connection is active. As a result, the Value Abbreviation field is empty for the abbreviation CORR.


Activities

To deactivate the automatic transport connection, enter the value X for the abbreviation CORR. You must do this if  you want to maintain the settings for the organizational structure in the user interface.


Eskom Configuration: This option not used, default.




3.png

Use


In this Customizing activity, you activate the applications that can be used in your client system.

In the default delivery system, there are three application components that can be activated:


  • GRC-PC for Process Control
  • GRC-RM for Risk Management
  • GRM-AC for Access Control


Activities


To activate an application component, proceed as follows:


  1. 1. Choose New Entries.

1.png

 

 

  2. Select an application component from the dropdown list.

  3. In the column Active, select the checkbox if you want to activate the application. If you are using both Process Control and Risk Management, you must set the indicator for both components.

  4. Save the entries.

The purpose of Emergency Access Management is to allow users to take responsibility for tasks outside their normal job function. This component allows temporary access for users when assigned with solving a problem, giving them provisionally broad, but regulated access which is monitored and recorded in the application.


SAP GRC 10.0 provides two different types of firefighting which can be used either centralized or decentralized. Following a short description of both types which can be configured in IMG using parameter 4000 (Application Type). Only one type can be configured at a given time.

 

ID-Based Firefighting

With ID-Based Firefighter each Firefighter ID has its own user master record with roles assigned directly to the Firefighter ID. The End-user (Firefighter) executes a transaction code and checks out an ID. It is possible for multiple users to check-out each Firefighter ID (which is authorized to the end-user) but only one user can have a Firefighter ID checked out at any time. A reason code and the expected activity must be documented prior to gaining Firefighter access. Relevant changes in SAP are captured in the change history under the Firefighter ID. It is important to highlight that everything is documented with the Firefighter ID and not the user’s normal user ID.

 

Role-Based Firefighting

Each role which is defined as Firefighter Role can be assigned directly to a user. This can be done through Access Request Management (ARM) if in place or directly in SU01. To use the Firefighter a user doesn’t have to check out a separate ID. Transactions and change histories are logged with the user’s own ID, which is an advantage in relation with the ID-based Firefighter. The end-user is not aware when he is utilizing emergency / firefighter access as he does not have to check out an ID and uses his own ID all the time.

 

Concept of ID-Based Firefighting

 

EAM_ID-Based_Firefighter.png

Concept of Role-Based Firefighting

 

EAM_Role-Based_Firefighter.png

Steps to set up ID-Based Firefighting

  1. Create Firefighter ID
    • Create a user account in transaction SU01 with user type S (Service) to be used as a firefighter. This can also be done in Access Request Management if in place.
    • Assign the Firefighter ID role which is defined in configuration parameter 4010 (Firefighter ID role name) to recognize the service user as a Firefighter ID.
    • Assign necessary roles for firefighter access.
  2. Define Firefighter Owner
    • Assign an Owner to the Firefighter ID
  3. Assign Firefighter Controller
    • Assign a Controller to the Firefighter ID. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter ID Controllers can also be Firefighter ID Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter ID.
    • The user can access the Firefighter IDs (can be more than one) within the validity dates.

 

Steps to set up Role-Based Firefighting

  1. Define Firefighter Role
    • Enable a specific role for Firefighting directly in the Business Role Management.
  2. Define Firefighter Role Owner
    • Assign an Owner to the Firefighter Role.
  3. Create Firefighter Role Controller
    • Assign a Controller to the Firefighter Role. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter Role Controllers can also be Firefighter Role Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter Role.
    • The user can access the Firefighter Roles (can be more than one) within the validity dates.

 

Please share your thoughts of both firefighting concepts and participate in upcoming discussions.


Best regards,

Alessandro

Access Control: - Create Access Request Using Web Service in GRC10



In this blog I would like to share my experience how Web service can be tested and create Access Request from GRC system when you are integrating with IDM system.

 

Suppose you have integrated GRC10 with IDM 7.2 and wanted to submit access request from IDM to GRC. Being a GRC consultant you can test Web Service used to create Access Request from GRC side. It helps to check Web Service is working and you are able to submit request and its following MSMP workflow created in GRC10 by you. Once this is tested from GRC side it’s easier to use same inputs from IDM side and submit Access Request to GRC.

 

 

Web Service used to create access request from GRC is GRAC_USER_ACCES_WS (User Access Request Service) .

 

Follow below steps to execute Web Service.

 

Execute Tcode SE80 and double click on Repository Information System


1.png


Expand Enterprise Services under Repository Information System and double click on Service Definitions .


2.png


In Application Component enter GRC-AC and Execute.

Now you will be able to see all Web Service used for IDM- GRC Integration

Here double click on highlight Web Service GRAC_USER_ACCES_WS (User Access Request Service ) .



3.png


And execute GRAC_USER_ACCES_WS (User Access Request Service) from below screen


4.png


Below pop up will come. Select Generate Request Template and execute.5.png



Below output will come. From here click on XML editor and provide required details in XML tags. And execute. This will create access request in response if you have provided all the details correct. If details are not correct then you will receive Error in response .


6.png



In above Web Service there are 5 Sections as below.

 

  1. CustomFieldsVal
  2. Parameter
  3. RequestHeaderData
  4. User Info
  5. Requested Line Item

 

Mandatory fields and User information are determined based on End user Personalization (EUP) in SPRO.  ReqInitSystem in Request Header data is mandatory filed and you need to provide IDM connector information in this.

 

 

Fill details in Header data , Line Item and User Info based on your configuration

 

Header DATA-

 

<RequestHeaderData>
<Reqtype>String 12</Reqtype>
<Priority>String 13</Priority>
<ReqDueDate>String 14</ReqDueDate>
<ReqInitSystem>String 15</ReqInitSystem>
<Requestorid>String 16</Requestorid>
<Email>String 17</Email>
<RequestReason>String 18</RequestReason>
<Funcarea>String 19</Funcarea>
<Bproc>String 20</Bproc>
</RequestHeaderData>

 

Line Item Details-

 

<item>
<ItemName>String 21</ItemName>
<Connector>String 22</Connector>
<ProvItemType>String 23</ProvItemType>
<ProvType>String 24</ProvType>
<AssignmentType>String 25</AssignmentType>
<ProvStatus>String 26</ProvStatus>
<ValidFrom>String 27</ValidFrom>
<ValidTo>String 28</ValidTo>
<FfOwner>String 29</FfOwner>
<Comments>String 30</Comments>
<ProvAction>String 31</ProvAction>
<RoleType>String 32</RoleType>
</item>

 

 

 

User Info

 

</item>
</UserGroup>
<UserInfo>
<item>
<Userid>String 49</Userid>
<Title>String 50</Title>
<Fname>String 51</Fname>
<Lname>String 52</Lname>
<SncName>String 53</SncName>
<UnsecSnc>String 54</UnsecSnc>
<Accno>String 55</Accno>
<UserGroup>String 56</UserGroup>
<ValidFrom>String 57</ValidFrom>
<ValidTo>String 58</ValidTo>
<Empposition>String 59</Empposition>
<Empjob>String 60</Empjob>
<Personnelno>String 61</Personnelno>
<Personnelarea>String 62</Personnelarea>
<CommMethod>String 63</CommMethod>
<Fax>String 64</Fax>
<Email>String 65</Email>
<Telnumber>String 66</Telnumber>
<Department>String 67</Department>
<Company>String 68</Company>
<Location>String 69</Location>
<Costcenter>String 70</Costcenter>
<Printer>String 71</Printer>
<Orgunit>String 72</Orgunit>
<Emptype>String 73</Emptype>
<Manager>String 74</Manager>
<ManagerEmail>String 75</ManagerEmail>
<ManagerFirstname>String 76</ManagerFirstname>
<ManagerLastname>String 77</ManagerLastname>
<StartMenu>String 78</StartMenu>
<LogonLang>String 79</LogonLang>
<DecNotation>String 80</DecNotation>
<DateFormat>String 81</DateFormat>
<Alias>String 82</Alias>
<UserType>String 83</UserType>
</item>

 

 

 

Kind Of Error / SUCCESS message you can get in response.

 

1.

 

<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <MsgNo>4</MsgNo>

  <MsgType>ERROR</MsgType>

  <MsgStatement>Invalid request initiation system</MsgStatement>

  </MsgReturn>

  <RequestId />

  <RequestNo />

  </n0:GracIdmUsrAccsReqServicesResponse>



2.

 

<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <   MsgNo>4</MsgNo>

  <MsgType>ERROR</MsgType>

  <MsgStatement>Invalid request type</MsgStatement>

  </MsgReturn>

  <RequestId />

  <RequestNo />

  </n0:GracIdmUsrAccsReqServicesResponse>

 


3.

 

<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <MsgNo>4</MsgNo>

  <MsgType>ERROR</MsgType>

  <MsgStatement>Invalid priority type</MsgStatement>

  </MsgReturn>

  <RequestId />

  <RequestNo />

  </n0:GracIdmUsrAccsReqServicesResponse>

 

 

4.

 

<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <MsgNo>4</MsgNo>

  <MsgType>ERROR</MsgType>

  <MsgStatement>Invalid Provision Action in line no 1</MsgStatement>

  </MsgReturn>

  <RequestId />

  <RequestNo />

  </n0:GracIdmUsrAccsReqServicesResponse>



5. When you provide al the required detail correct. SUCCESS response will be received.

 

<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <MsgNo>0</MsgNo>

  <MsgType>SUCCESS</MsgType>

  <MsgStatement>Request created successfully</MsgStatement>

  </MsgReturn>

  <RequestId>ACCREQ/984BE1639ED01ED3A0D7D9B2BE664366</RequestId>

  <RequestNo>1000001159</RequestNo>

  </n0:GracIdmUsrAccsReqServicesResponse>

 

 

6. One strange issue I have seen. If you are creating access request with user missing with GRAC_SYS auth object then you can get “Connector not configured Error”

 

 

Same type of error message you can get in IDM- VDS logs when Access Request is submitted via IDM.

 

Hope this will help you to understand Access Request creation using Web Service and test Web Service.

 

Regards

Dilip Jaiswal

In GRC 10.0 SAP has introduced the Centralized Emergency Access Management process unlike its older version GRC 5.3 which got mixed reviews from GRC users.


Initially a user has submitted his idea in SAP IDEA PLACE asking SAP to provide De-centralized logon in GRC 10.0 in the same way they have been using in GRC 5.3 and this has been supported by lot of GRC consultants.


https://ideas.sap.com/ct/ct_a_view_idea.bix?c=4F27C74D-5330-4569-8199-D69072C0D4AE&idea_id=5C643027-DCA7-4CB1-871E-BFFAF3A072B3


Finally SAP has enabled De-centralized firefighting feature in GRC 10.0 from GRC SP10. Depending on the client's needs, the option "log on centrally" (current version 10 behavior) or "log on locally" (5.3 behavior) can be configured in GRC 10.


Also system had the ability where both centralized and de-centralized approach can be configured but user can either login centrally or locally as there can be only one firefighter session at a time.


De-centralized EAM configuration – SP13 – ID based Firefighting


Step 1: Creating Connector and Assigning Integration Scenarios


Creating Connector:


  • Create new connector using SM59 Tcode or going through below mentioned path.


SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Create Connectors

 

  • Create ABAP connector with the options as shown below.



  • Under Logon & Security maintain the details as shown below. User RFC_USER is a system user and is available in ECD system with S_RFC access.



  • Once you have maintained all these values. Save the connector and then click on Connection Test. If it is successful, you will get below screen.



Maintain Connectors and Connection Types


  • Now click on Maintain connectors and Connection Types going to below path as this is required for assigning the connection type to our connector which is created in the above step.


 

  • You will get the below screen where you can see different types of connection types available in the GRC system.


 

  • Maintain the entries for your connector as mentioned below. Source connector is not required. Change the setting “Max No. of BG...“parameters to “3“ (i.e. this connector will use a maximum of 3 background jobs for synch jobs)



  • Now our connector needs to be assigned connector group. This is similar to logical system in GRC 5.3 where we group similar systems under one logical system. You can create your own connector group or else, when you activate BC sets for SOD rules automatically connector groups gets created in the system which were used in the SOD rules. Then you can assign your connector to the connector group as shown below.


 

  • Once you have these connector groups, then assign the connector group to group type as shown below.

 

 

  • Next step is to assign connectors to connector group as shown below.



Maintain Connection Settings


  • Connectors must be assigned to the all integration scenarios (AM, ROLMG, SUPMG, AUTH, PROV) available as it is a good practice according to SAP (under Common Component Settings -> Integration Framework -> Maintain Connector Settings). In the same way mentioned below repeat for ROLMG, SUPMG and PROV scenarios.



Maintain Connector Settings

 

  • Now go to below mentioned path for maintaining connectors with application types and enabling PSS.

 

 

 


Maintain Mapping for actions and Connector Groups


  • For POC purpose we are connecting GRC 10 system to ECC system and hence only one Connector group is there in active status.


 

  • From the same screen we can define default connector to be used for different actions as shown below.

 

 

For example if you are creating LDAP connector then the mapping between AC and LDAP fields are maintained in assign group field mapping. Once all the above mentioned steps are performed, then the next step would be to schedule the synchronization jobs in the order advised by SAP.

 

Step 2: Creating FF Users, FF Owners, FF Controllers in GRC 10

 

  • FF Users executes Tcode /n/GRCPI/GRIA_EAM from Plug-in system and login with firefighter Id’s assigned to them. So users no need to exist in GRC system any more.

 

  • Following two roles must be assigned to the Firefighter user.

SAP_GRC_FN_BUSINESS_USER  &

SAP_GRC_FN_BASE.

for the centralization as well as Decentralization.


  • FF Id’s will be created in plug-in system and assign the role SAP_GRAC_SPM_FFID or its “Y” or “Z” equivalent to make it recognizable as FF Id.

 

  • FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.

       NWBC -> Setup -> SuperUser Assignment and NWBC -> Setup -> SuperUser Maintenance


  •     FF Controller should also exist in the plug-in system with valid Email ID as FF login notifications will be sent to controller’s Mail Id maintained in plug-in system.

 

  •    FF log notifications are sent to FF controller’s mailed maintained in GRC system. Hence FF controller should exist in both GRC and Plug-in systems.

 

Step 3: Synchronization Jobs in GRC 10


In GRC 10 synchronization jobs can be run from SPRO->IMG, navigating to Governance, Risk & Compliance>Access Control>Synchronization Jobs

Authorization Synch
Synchronizes PFCG Authorization data

Repository Object Synch
Synchronizes Profiles, Roles, and Users master data

Action Usage Synch
Synchronizes action usage data

Role Usage Synch
Synchronize role usage data

Firefighter Log Synch

Synchronizes the firefighter logs from plug-in system to GRC system

 

Firefighter Workflow Synch

Initiates FF log report review workflow based up on your workflow settings which sends the FF log report to FF controller for review.

 

EAM Master Data Synch

This is the new job introduced as part of De-centralized firefighting. Synchronizes the EAM data from GRC box to Plug-in system. Once you have created all required users execute this job to synchronize the data from GRC to plug-in system.

These reports can also be maintained as scheduled background jobs.

 

 

 

 

Step 4: Configuration Parameters


SAP has introduced a new configuration parameter 4015 which has to be maintained as “YES” in order to enable De-centralized firefighting as shown below.


Configuration Parameters – GRC system



Configuration Parameters – Plug-in system


 

 

Step 5: Assigning FF Ids to Users


Unable to find FF Id’s in NWBC.


  1. Please check whether configuration parameters are maintained as mentioned in step 3.
  2. Please check whether all synchronization jobs are executed as mentioned in step 2.
  3. Please check whether the user who is searching for FF ID’s in NWBC has required access.
  4. Please check the below mentioned configuration also.

 

Assign Owner, and Controller:


Without assigning an owner and a controller, you might not be able to assign the FF ID to a Firefighter. From NWBC –> Setup –> Super User Assignment, assign Owner, and NWBC –> Setup –> Super user Maintenance, assign Controller.

Now you can assign the Firefighter Id to Firefighters either directly or through GRC access request.


   5. In plug-in system you will find all the FF roles required for user, controller etc. You need to create Y or Z copy of them and should assign them to the users.

 

 

Step 6: FF ID is assigned to the FF User


  • FF user has been assigned with the FF Id.

 

  • Now FF Users executes the Tcode /n/GRCPI/GRIA_EAM in plug-in system and can see the FF Id assigned to his User ID. When FF users tries to login with the FF Id assigned user will get the below error.

 


  • We already has RFC connector SECCLNT100 created in GRC system to connect from GRC to SEC and vice-versa. This error was resolved after creating RFC connection locally by the same name SECCLNT100 as system is expecting a local RFC connection with the same name.

 

  • Once this issue is fixed, users are able to login as Firefighters from plug-in systems and complete their tasks.

 

Step 7: Fire fighter Login and Log notifications


Configurations required for the Login Notification:


  1. In the GRC Box, maintain configuration parameters as mentioned above in Step 4.
  2. Make sure that 'EAM master sync job' is complete.
  3. Into the Plug-in system, maintain configuration parameters as mentioned above in Step 4.
  4. In the Plug-in system, FFID controller must exist with a valid email Id, as email notification is sent from the Plug-in system.
  5. Login notification mail will be sent from Firefighter User SU01 Mail Id itself in de-centralized model. Make sure that email Id of the firefighter User is also maintained properly.
  6. FF User time zone and system time zone should be the same in plug-in system.

 

Login Notification sent from Plug-in system:



Configurations required for the Log report Notification


Unlike Login notification, Log Report notification is sent from the GRC Box. Almost, all of the steps are same as in case of centralization.

  1. Make sure that the configuration parameter 4002 is maintained into the GRC BOX.
    1. If the 4007 is set to 'Yes' then schedule only job 'GRAC_SPM_LOG_SYNC_UPDATE'. This job will send the Log Report notification as well.
    2. If the 4007 is set to 'NO' then schedule job GRAC_SPM_LOG_SYNC_UPDATE for synchronization. It will not send the Log Report Notification. For the Log Report, another job is required to be scheduled which is 'GRAC_SPM_WORKFLOW_SYNC'.
  2. Controller of the FFID is configured with the valid Email Id.
  3. In the NWBC -> Access Management -> Controller -> make sure that 'Notification By' column is selected to 'Email'.
  4. Make sure that 'EAM master sync job' is complete.
  5. There is no setting which is required to be maintained into Plug-in system in this case.

 

Log Notification sent from GRC system

 

.

 

Firefighter Login Issues - Plug-in system


Login as firefighter using Tcode /n/GRCPI/GRIA_EAM

User will enter the reason code and activity details and click OK.

User will be presented with a login screen.

 

Fix

User should be assigned to the below roles and make sure user also has access to S_USER_GRP object with Activity 03,05


SAP_GRAC_SUPER_USER_MGMT_USER

SAP_GRC_FN_BASE

SAP_GRC_FN_BUSINESS_USER


EAM for Webdynpro and Web based applications


Firefighter functionality is primarily designed for use with ABAP systems. Lot of us had a requirement to implement EAM for webdynpro or web based applications, but there are lot of limitations for using EAM for webdynpro and web based applications.


To understand about EAM functionality with Webdynpro applications,  please check out the below blog post.


Emergency Access Management (EAM) for Webdynpro applications or Web-based applications - GRC 10.0

Many thanks to Amanjit and Colleen for their guidance.

 

In case there is a business need to have single approval for Manager & Role Owner where both happens to be the same person, below is the solution:

 

 

This can be achieved using Multiple DBLookups....in this case 4 DBLookups:

 

1. Get Request ID

2. Get Role ID

3. Get the Manager ID

4. Get the Role Approver ID

 

 

Following are the steps:

 

Step 1: Get Request ID

 

Request ID is in GRACREQ (Request Header) where REQNO = Request.ReqNo (select from context parameter) . This will be used as expression in Manager ID Table to get the Manager for this Request only and not any other request.

 

3.JPG

 

Step 2: Get Role ID

 

Request ID is in GRACROLE (Role) where Role_Name=Request.Role_Name (select from context parameter) . This will be used as expression in Role ID Table to get the Role for this Request only and not any other request.

 

4.JPG

 

 

Step 3: Get Manager ID

 

Now create DBLookup for Manager ID. Manager ID is in GRACREQOWNER Table with Req_ID=Get_REQ_ID (Request No from Step 1) and UserType="MAN". Put that ID in a variable lets say User ID.

 

1.JPG

 

 

 

Step 4: Get Role Approver ID

 

Role Approver ID is in GRACROLEAPPRVR Table where Role_ID=Get_Role_ID (Role ID from Step 2).We can put that in Approver Variable.

 

2.JPG

 

 

 

Step 5: Create Condition in Decision Table

 

Create simple condition that if DBLOOKUP-MGR=DBLOOKUP-ROW (Manager = Role Owner) then True otherwise False.

 

5.JPG

 

 

 

Hope this helps.

 

Best Regards.

 

Shahid.

Hi experts,

 

While creating Risks and Opportunities, the system provides for selection of Risk Category. There is an option to assign an Activity also to the Risk being created.

 

I feel the need for another field to select, ie. the Activity Category. There are huge number of activities which are created as sub-processes in Business Process hiearchy and in other categories like Projects, Company Assets and Planning objects, to site a few. It is a good feature that the system allows sub-categories also.

While creating Activity, activity is  assigned to an Organisation and to an Activity Category. This category should be avaiable for selection in Risk creation and the system should filter the activities according to the Activity Category/Sub-Category chosen.

 

Hope others also feel the same way.

Regards

KS.

Hi All,

 

I need all your help to get me some documents in regard to GRC process control,I went through all the links which was given by all our friends,I am bit confused what to read and what not to read or sequence ,which documents need to go through step by step,can some body guide me on this..

 

Regards,

 

Ravi

Actions

Filter Blog

By author:
By date:
By tag: