A common need for many companies is tocustomize access request and approval ABAP Web Dynpro screens of 10.0 and 10.1 based on the business requirements. Though the IMG customizing in SAP GRC access control provides some alternative to accomplish this, there is another Web Dynpro feature which can be utilized to do additional screen modifications without any additional coding effort for all the users.

Below steps would explain it for access request submission and approval screen:-

Access Request Submission

1. Go to Transaction SE80 and Open package GRAC_ACCESS_REQUEST.

2.  Drill down to Web Dynpro->Web Dynpro Application

3. Select the application GRAC_OIF_REQUEST_SUBMISSION and double click

4. From the menu choose Web Dynpro Application-> Test -> In Browser - Admin Mode

5. Hiding Field/Tab

       i. Place the cursor at the field or the tab that needs to be customized and right click and choose 'Settings for Current Configuration'.

ii. Change the Visibility property to 'Invisible'. Save and Close.

6. Customizing ALV

i. Place the cursor at the ALV to be customized e.g. ALV under User Access tab and right click and choose 'Settings for Current Configuration'.

ii. Add/Remove columns, change sequence etc. Save and Close

8. Above steps can also be done for other UI elements present on pop ups that open through access request submission screen like: Existing Assignments etc.

7. Launch the access request submission through NWBC to see the effects

Access Request Approval

Modifying access request approval screen is little tricky as it requires as GUID to be passed externally in the URL, apart from that the other steps are similar to access request submission explained above.

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

2. Click execute button and copy the value of field REQ_ID

3. Select the application GRAC_OIF_REQUEST_APPROVAL and double click

4. From the menu choose Web Dynpro Application-> Test -> In Browser - Admin Mode

5. Below dump screen will be launched initially.

6. Append the string &OBJECT_ID=ACCREQ/<REQ_ID copied in step 2> e.g. &OBJECT_ID=ACCREQ/4CC001105B2A42DCE10000000A421B2B in the URL displayed in Step 5. Approval screen should be launched correctly after that.

7. Customize the UI similar to how it was done for access request submission screen.

The above process can be done for any Web Dynpro application. To find the Web Dynpro application name, right click on any ABAP Web Dynpro screen and choose option More Field Help.

This blog is intended to outline future product direction, and is not a commitment by SAP to deliver any given code or functionality. Any statements contained in this blog that are not historical facts are forward-looking statements. SAP undertakes no obligation to publicly update or revise any forward-looking statements. All forward looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. The timing or release of any product described in this document remains at the sole discretion of SAP. This blog is for informational purposes and may not be incorporated into a contract. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

• SAP AC on HANA
• Enhanced User Interface - Corbu Theme
  
• Context-Based Side Panels
• New Access Request and Approval Forms - Simplified & steamlined interface
• Remediation View – unified remediation processes from one location
• Custom User Groups
• Reporting and Dashboard improvements
• Dashboard Drill Through and Analysis
• Decentralized Firefighting (SAP Access Control 10.0 and 10.1)
• Role Search Personalization
• Business Role Improvements

To activate the End User Logon screen, To maintain the logon information, do the following: -

1. Execute transaction SICF.
2. In the Service Name, enter the name of the service - GRAC_UIBB_END_USER_LOGIN
3. Click the Execute button.
4. Under the Virtual Hosts / Services column you will see the service selected service. Double click on this service name.
5. Click on the Logon Data tab.
6. Click on the Pencil icon to go to change mode.
7. Enter the information for the client, shared user, language and password and the user should be select Internet type User.

Note: Create user with below roles and user type is service type

• SAP_GRAC_SUPER_USER_MGMT_USER
• SAP_GRAC_ACCESS_REQUESTER
• SAP_GRAC_BASE
• SAP_GRAC_END_USER
• SAP_GRAC_NWBC
• SAP_GRAC_SPM_FFID
• SAP_GRC_FN_BASE
• SAP_GRC_FN_BUSINESS_USER

8. Click on save.

Do the same procedure for all the services mentioned below. Maintain same user details in all the services and the user should be of type Internet user

1.      GRAC_OIF_MY_PROFILE_EU

2.      GRAC_GAF_NAME_CHANGE_SERV_EU

3.      GRAC_POWL_REQUEST_STATUS_EU

4.      GRAC_GAF_PWD_SELFSERVICE_EU

5.      GRAC_OIF_USER_REGISTER_EU

6.      GRAC_GAF_ACCREQ_WITH_REQREF_EU

7.      GRAC_OIF_REQUEST_SUBMISSION_EU

8.      GRAC_GAF_ACCREQ_WITH_TEMPL_EU

9.      GRAC_GAF_ACCREQ_WITH_USEREF_EU

1. Save the entry and navigate back to the Maintain Service screen.
2. Right-click GRAC_UIBB_END_USERLOGIN, and then choose Test Service.
3. The End User Logon screen appears. The http URL displayed in the browser's address window is the End User Logon URL.
4. To set the links the application displays on the End User Logonscreen, continue with the following steps:
5. In the URL window of the browser (from step 4), append this to the end of the URL: &SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/123and press Enter. The Logonscreen appears.
6. Enter your username and password, and log onto the system. TheEnd User screen appears.

If you getting any Login errors like user ID does not exist, then you need to maintain

“User Authentication Data Sources is SU01(If you have HR System then you select HR) and

set NO in End User Verification” in Maintain Data Sources Configuration.

8. To make a link invisible, right-click the link and select Settings for Current Configuration.

9. Select Invisible, Save the entry, and then close the browser.

Thanks,

Rajesh Srisailapu.

Governance, Risk, and Compliance are some of the terms which almost everyone is afraid of. Process audits can be disastrous if these terms have not been given a deep thought while analysing, designing and operating on various processes running within the organisation. Processes can make or break an organisation, if processes are non-compliant and exposes an organisation to a range of risks, its better to get rid of them as those may cost you and your organisations a fortune.

Processes defines the character of an organisation as those govern behaviour, strategies, future and ultimately the destiny of an organisation very much like values, habits and traits defines the character of an individuals and help in triumphing the journey of life.

For better process governance and to avoid risks, businesses continuously or periodically check the processes. This gives business an opportunity to get insight of the process, its exceptions and verify the input and output data to check if it is compliant.

The Tool: Security Weaver- Process Auditor

Recently, I got the opportunity to work on a GRC tool from Security Weaver. In this blog, I am sharing my implementation experiences on “Process Auditor -PA”.

Process Auditor also called Security Weaver-PA, is a bolt-on solution to SAP and does not need any additional portal/web access. This tool is well integrated with SAP and therefore does not need full range of batch jobs to run to pull data from SAP database, the actual tool can be accessed through SAP GUI once the user logs in. The tool can be called with the help of transaction codes (/n/PSYNG/PA) within SAP. Access to tool can be controlled by SAP authorisations.

Process Auditor- “Controls”:

The Process Auditor tool comes with its own standard “Controls”, which can be easily implemented as per business needs and requirements. The tool gives a perfect platform to further customise and develop these basic standard controls, as per business needs. These controls cover all business areas and SAP modules. Some of the high interest controls which shall pick business attention almost immediately are:

Purchasing controls: (PTP)

1. Duplicate vendor invoices
2. Duplicate vendor payments
3. Employees and vendors with the same bank details
4. Purchase Req and corresponding Purchase Order approved by same person
5. Duplicate vendors in the system, having same bank details
6. Employees and Vendors with Same Name or Address
7. Changes in Payment Terms for customer or Vendors

Sales controls: (OTC)

1. Ageing Analysis of Sales Returns
2. Employees and customers with the same bank details
3. Changes in Credit Exposure for Customer by Credit Control Area
4. Credit Check in Sales Order Processing
5. Sales through One time Customers
6. Credit Exposure for Customer Risk Category
7. Changes in Payment Terms for customer or Vendors
8. Sales Cancellation

Finance controls: (RTR)

1. GL Account Changes Company Wide
2. Monitoring Exchange Rate Changes
3. Employees and Vendors with same Bank accounts
4. Changes in Bank Details in Vendor Master
5. Journal Entries Posted and Parked by the same person

System controls: (IT)

1. Detect Changes Made in Production Client Settings
2. Detect Unauthorized Changes in Technical Settings of Tables
3. Detect SAP Data Transport By Unauthorized User
4. Detect ABAP Programs Not Assigned To Authorization Group

In essence, these controls can cover SAP configuration, master data and transactional data aspects to touch base with every process running in your organisation to identify the potential risks.

The tool further gives an excellent platform to customise these standard controls and help in preparing a framework to run these controls with a logical approach.

Output of a control run:

The outcome of the control run is potential risk “cases” which have got the data records identified. A case may have several data records as per the definition of the control. The control can have the business ownership within the tool and therefore the cases generated will also have the business owner who will take action on these cases or can delegate someone to take action further.

These records within the case generated, are then analysed by the business and appropriate action is taken on data records or cases can be closed with suitable comments without action.

Over a period, the tool can hold full history of these control runs and appropriate actions & comments filled in by the business owners.

An example of control- Duplicate vendor invoice/payment control:

Many people would say that identifying duplicate vendor invoices is an easy task, we can design a report to cross check the SAP invoice reference number (vendor invoice number) and identify if these numbers are same. Its not that simple as this reference number is manually keyed in, there are chances that a space, additional number or fake invoice number has been keyed in. A invoice can be create with or without a PO reference or with different vendor accounts which belongs to the same vendor.

Moreover, a typical SAP system may also have some invoicing tools as interfaces, which are sending invoices into the system like e-invoicing tools OB10, Ariba etc.

Also, there are other payment channels and processes outside accounts payable like direct debit, BACS, CHAPS, Procurement card payments, One time vendor payment, subsequent debit, and advance against PO etc. The duplicate invoice might be a week or 15 months old you are not sure.

We actually need to consider all channels of payments and invoicing, potential vendor master data duplication, invoice amount, currency, invoice date, vendor bank details and finance journal postings etc. There are companies which gives consulting services just to identify duplicate vendor invoices and charge a percentage of identified duplicate amounts for their services.

With the help of Process auditor, we could consider all aspects of vendor invoicing and payments as mentioned above and could easily enhance the controls to our business needs. Now we have a framework covering all aspects to identify vendor duplicate payments. This is protecting the business of paying any duplicate vendor invoice. Also, has reduced a lot of manual work which goes in to identify such duplicates.

Over a period the project costs will be covered by the corresponding savings made by the business.

I hope I could cover all aspects of Security Weaver – Process Auditor controls to give you glimpse of the tool features and how it can help in auditing the processes.

Regards,

Ravi Pachauri 

SAP GRC AC 10.1 Enhancements

GRC consultants might be curious to read and see the new feature that came in GRC AC 10.1. So here comes a glimpse of some key enhancements and its configuration that has been incorporated in SAP GRC AC 10.1.

GRC Access Control version 10.1 look and feel is almost similar to version 10 except few additional options that SAP has included based on customer feedback. The new changes predominantly focus on HANA integration, access request, rule set creation and enhanced remediation process.

1. Disable link functionality in attachment and Links:

This option helps customer to enable or disable link functionality in access request.

In Access request, by default ‘Add file’ and ‘Add Link’ option are enabled (see below):

We can use this disable ‘Add Link” functionality of GRC Access Request to disable the 'Add Link' Functionality.

Disable the link:

Link got Disabled (see below)

2. New connection HANA Database Connection Type

GRC AC 10.1 is provided with a new connection type – HDB (HANA Database).

GRC can be integrated with HANA or I would say instead Oracle, GRC AC 10.1 can use HANA as database to store master data. GRC can even do user management for HANA system similar to any other SAP systems. With HANA, GRC can be used for analytic and can provide analytical reports on roles and users.

If you are using SAP HANA database, make sure that plug-in SAP GRC 10.1 Plug-In SAP HANA is installed.

3. Maintain Firefighter ID role name per connector

GRC AC 10.1 came up with this new feature to maintain Firefighter ID role name per system/connector. Instead of maintaining the SPM role in configuration parameter we can utilize the new option to map FF ID role per connector.

4. Organization rule creation wizard

Sometime client’s uses dummy controls or deactivated some risk to avoid false positive, GRC AC 10.1 brings one excellent feature to create organizational role using a wizard to avoid false positive. You can create Org rule using this wizard and can even also download and upload it in other system. No need to bother about the org fields or value which you will use to create org rule. GRC AC 10.1 will guide in all possible way.

To create organizational rule you can use below option under IMG or there is an option available in NWBC as well.

IMG - SPRO:

Later on we can download and upload the organizational rule using Additional rule upload and download option.

NWBC:

5. Configure Attributes for Role search criteria in Access requests

This feature I would feel give more benefits to end user who raise CUP request on daily basis.

While raising CUP request, requester has to search for role based on business process, Functional area or some other role attributes. Some of the key search criteria are visible straight away there but some other requestor has to add manually.

Now with this new feature we can customize the search criteria screen and can make only the important search criteria visible in search request so that requester can fill in the details and can search the roles.

We can even set the default values for those criteria.

Role Search screen

IMG (SPRO) Customization      

     Search criteria got changed as per customization done in above screen.

6. Simplified Access Request

Simplified Access Request is one more excellent feature that will give benefits to requester who does the following frequently:

   1. Assign role to user

   2. Remove role from user

   3. Extend the validity of existing role

With this option users does not have fill all the fields which normally appear in normal access request. Simplified access request form will ask for least information to perform the activity.

See below Simplified Access Request Screen:

Review and Submit: this button is used to review the request for risk and submit it for approval

Save Draft: you can save the access request and can review and submit it later

Open in advance Mode: Open the request in normal access request screen.

Reset:  Reset the fields

Risk Analysis: Run risk analysis on the role selected for provisioning and can even suggest mitigating.

This is an excellent feature which gives us a detailed risk analysis report (risk/role view) and even provides an option to mitigate the risk before submitting the request.

System added roles: It will bring out the default roles or mapped role added by the system itself if any.

This screen is built on UI5 and can be customized by using below four options:

We can customize the display section (User details, Request details and Customer info (not visible by default))

Field levels can also be customized.

We can also set some set of request reasons which can be seen and selected during request creation to save time and effort

There is no separate workflow configuration for simplified access request. It follows the same MSMP configuration maintained for normal access request. The request created can be seen under “Work Inbox – Simplified (see below)” in NWBC as well as in normal work inbox request. It follows the same number range. So the processing and working of simplified access request is same only request submission screen is different.

My Inbox:

To check simplified access request

7. Risk analysis on SU01 Attributes

Sometimes business wants to perform risk analysis on SU01 attributes of user for ex: Function, department, parameters etc. GRC AC 10 does have this functionality but we can at max do risk analysis on user group level of users only.

In GRC AC 10.1 With this new enhanced feature we can now create custom group based on SU01 attributes as shown below and can perform risk analysis on the user belongs to that attributes

That GRC AC 10.1 is integrated with some of key attributes of SU01 which we can use a selection criteria to perform risk analysis

     Following are the attributes available:

Enter some attributes, search the users and perform the risk analysis.

We can save it as well so that same can be used later.

8. Remediation View

This is one the best feature and would be very much appreciated by business.

The main task or I would say pain start after implementing GRC AC is to make all users SOD free i.e. to be clean. For this we have to download user level detailed report and then analyze the root cause to see whether we can remediate or mitigate to be clean. Business is taking lots of time analyzing the report and deciding the solution.

Now GRC AC 10.1 has come up with a remediation view report where business itself can analyze all aspects of risk and also help business to take decision to be clean. This will save lots of time of business and can effectively guide business to take a decision to be SOD clean.

GRC AC 10.0 was having technical and business view of risk analysis. Now GRC AC 10.1 has come up with a new view called “Remediation View”

  Risk Analysis report:

This remediation view report will provide us a lot of option to remediate the risk then and there only.

We can mitigate the user on risk and rule from this screen itself. See below:

Or else we can remove the role by selecting remove role option. See below: 

The one of the greatest feature of GRC AC 10.1 comes into action when you choose remove role from remediation view screen

and a Change Account Access Request automatically gets created for removal of the role from user. See below:

That means we can initiate remediation (removing role) or mitigation (assigning control) for user from this screen. No need to download the report and then analyze the report to take a decision.

This view also provides all sort of detailed information on user, role and risk. To get the information click the user, risk, rule and role (all bold text). See below:

Note: GRC AC 10.1 runs smoothly on IE 9 and Chrome. New feature like Remediation view and simplified access request mandatorily need IE9 and Chrome. Remediation View will run in SAP Access Risk Analysis only when an SAP Netweaver Gateway connection is established. Please configure SAP Netweaver gateway as per the GRC AC 10.1 installation guide “ACPCRM_10-1_INSTALL”.

From now on you have the chance to explore the High Performance Application SAP Fraud Management completely for free in the cloud. Via the SAP HANA marketplace you can quickly order your free trial access by only pushing a button. Within less than two hours you are able to log on to the system and experience the applications features and great user experience.

Discover how the application supports you with a real time fraud detection to reduce financial loss. Learn how it helps you to minimize false positives through real-time calibration and simulation capabilities on very large volumes of data in order to improve the accuracy of the fraud detection. And see how it combines rules and predictive methods to optimize fraud scenario analysis and adapt measures to changing fraud patterns to better prevent fraud situations from happening.

The free trial version of SAP Fraud Management showcases a preconfigured “basic anti-bribery detection” scenario. In order to get to know all the capabilities of SAP Fraud Management, you have the possibility to start a pilot project running in the SAP HANA Enterprise Cloud. Within the pilot project, you can run the application with your own business data without investments in hardware. The cloud system is ready to use within a couple of days.

Besides the free trial and the pilot projects running in the cloud, SAP Fraud Management is productively available in the cloud as well. Which means that there are two fully supported deployment options for SAP Fraud Management: on-premise or in the SAP HANA Enterprise Cloud.

Sign up for your free trial today and enjoy SAP Fraud Management, powered by SAP HANA.

Parts of the US Export Control Reform went into effect on October 15th, 2013.  Are you ready?

The current system has two different control lists administered by two different departments, Commerce and State, and there are three primary export licensing agencies, Commerce, State, and the Treasury.  A multitude of agencies – Commerce, Defense, Homeland Security, Justice, State, and the Treasury – each have authority to investigate and/or enforce some or all of the export controls, each using separate IT systems that do not intercommunicate.

Why reform? There are many reasons. In addition to streamlining the process, it is for economic reasons.  The current export regulations encourage customers to source from non-U.S. suppliers when possible to avoid the U.S. licensing system. This harms U.S. manufacturers, diminishing their sales and driving up costs to the U.S. military for the same items.  According to a Department of Commerce industry survey, U.S. firms estimated that U.S. firms lost in excess of $2.1 billion annually in sales due to export controls and billions more in lost opportunities to even compete for a sale.

The ongoing reforms are forcing companies to re-evaluate how they comply with these regulations. How do you currently control exports of physical goods, digital goods and technical data? Do you rely on painful manual procedures or custom programming? The ongoing export control reform is a good time to pause and re-consider your current approach. SAP GTS, with NextLabs, can help automate export compliance for physical goods, digital goods and technical data.

Click here for more information on export control reform

Click here to attend an SAP-Deloitte webinar on Leading Practices for Global Export Compliance.

With this application, you can use the data that you have replicated from your SAP GRC system to SAP HANA, and monitor, analyze, and, in some cases, act on role-centric reports. SAP Role Analytics is an example of how you can create analytical reports and add functionality that allows you to take action on the analytical data.

The application has these reports:

·         Unused Roles

You can take action to de-provision unused roles.

·         Actively Used Roles

·         Orphaned Roles

You can access the application using an HTML5 supported web browser .The application counts the actively used, unused, and orphaned roles on the GRC system, combines it with the business process information, and displays this data in pie chart format. The default date range for the count is the current year. You can adjust the data by changing the date range, or by selecting filters for role type, landscape, criticality level, and sensitivity.

The default report isUnused Roles. You can choose to display the information in different formats: pie chart, bar chart, table. You can drill down by choosing any of the selectable elements in the charts and tables.

1)   ORPHANED ROLES

From the available options, select “Orphaned Roles.”

From the Sensitivity filter, when selecting “Confidential,” “Restricted,” and “Classified, the filter shows the selected 3 of the possible 10 choices under Sensitivity. Then automatically result gests refreshed graphically based on the selection criteria (pie chart).

From the result set, we can switch the pie chart to bar chart.

By double-clicking on the specific bar say the business process Quality Management roles bar in the graph, it will drill down the list of roles.

          2) UNUSED ROLES

Double click on the “Basis” section of the chart, bringing up a table of the roles and user counts involved.

The filters can be applied to check the roles for the specific land scape say SAP R/3

From the list, we can go through each of the roles in the SAP R3 systems that aren’t being used. Evenmore convenient, we can select to de-provision the role from the affected users. The de-provisioningrequest is sent directly to the backend Access Control system and the appropriate workflow is used withjust one click!

We can continue to use the SAP Access Control Role Analytics application to quickly and easily resolvethe remaining unused role issue and addresses Internal Audit’s concerns.

After having worked on GRC Process Controls (PC) 2.5, 3.0 and also with some hands on with 10.0, it’s great to have the opportunity to look at the latest SAP offerings within GRC PC 10.1. Ramp up testing is always great learning experience and I am lucky to have experienced this one.

I’m sure there is curiosity around the new version and therefore I thought I’d share some of my observations.

Although the look and feel seems similar to 10.0, we do have some new features for Process Controls with version 10.1.

1.  Assessments -> Planner

New survey categories introduced within the Planner “Disclosure Survey” which can be conducted at Organization, Sub process and Control level.

2.  Assessments -> Questions Library

Two new Question categories have been introduced:

• Workshop Survey
• Disclosure Survey

3.   Assessments -> Survey Library

Two new Survey categories have been introduced:

• Workshop Survey
• Disclosure Survey

4.  Assessments -> Reports

There have been 3 introductions within the list of PC evaluation reports.

Assessment Survey Details report provides detailed information in addition to the overview Assessment Survey Results report. Some of these details include Question, Answer, Assessment Processor, Comments, Case ID, etc thus providing a deep dive into the assessment details. Earlier versions had drill down capability to fetch such information about assessments. But with detailed reports mass processing becomes much easier.

With the introduction of Disclosure Surveys, 2 new reports related to this survey category have been introduced:

Disclosure Survey Details as the name suggests, provides a deep dive into the survey results.

Disclosure Survey Status as the name suggests, provides information about the status of the survey.

5.   Side Panel

With PC 10.1 we see the introduction of Side Panels. These provide additional overview information which helps us connect between for example: Organizations and assessments in one go. Although these may require additional configuration.

6.    SPRO changes

Import and export of business rules functionality is new within GRC 10.1. This functionality will enable SAP delivered business rules (configurable / programmed) to be imported into the GRC system and exported to other systems too by converting them to a downloadable format (like XML).

In addition to the above, with 10.1 SAP has also included features like Role-based Entry pages, Google like search and End to End Evaluations using offline Adobe forms which can be configured based on client's requirements.

I'm sure there is still more that I will discover as I spend more time with GRC PC 10.1. I will keep you posted on more findings and experiences!

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

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.

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.

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.

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. 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)

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

1. 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.
2. 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.
3. FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.

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

   4.    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.

   5.    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

1. FF user has been assigned with the FF Id.
2. 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.
4. 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.
5. 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

.

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.

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.

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.

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.

Step 5: Create Condition in Decision Table

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

Hope this helps.

Best Regards.

Shahid.

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

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

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 ) .

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

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

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 .

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

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

Concept of Role-Based Firefighting

Steps to set up ID-Based Firefighting

1. Create Firefighter ID
   • Create a user account in transaction SU01 with user type “System” 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 system 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

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.

  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.

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.

SPRO Location

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

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

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