2-4-0 Acr1 Detailed Level Design 1-Rev2

Access Control Product:
Detailed Level Design
Documenting the detailed solution design; capturing

how the solution will need to be configured in order to
meet the business requirements
Author(s): Fahri Batur
Issue Date: 4th November 2013
Version: v1.0
Contact: Fahri Batur

+971 (0)55 207 2998
fahri.batur@integrc.com
Contents
1. Document Details...................................................................................................................... 3
2. Cross Application Design.........................................................................................................5
3. SAP GRC Plug-in.......................................................................................................................9
4. Connecting the User Data Source.........................................................................................12
5. Cross Module Configuration Parameters..............................................................................15
6. Organisational Structure........................................................................................................ 16
7. Access Risk Analysis............................................................................................................. 17
8. Emergency Access Management.......................................................................................... 20
9. Access Request Management................................................................................................21
10. Business Role Management...................................................................................................28
11. Appendix One: Background Jobs......................................................................................... 31
2. Detailed Level Design www.integrc.com

1. Document Details
The document management details are shown in the section below.
Document Distribution
Integrc: Version 1.0

 Fahri Batur
Client:
 Hind Obaid Saeed Al Falasi
Document Change Control

Document change history is detailed below.
Date Version Author Changes
4th November 2013 1.0 Fahri Batur Initial version
Document Purpose
This document provides a detailed level of the solution relating to Access Control requirements and
documents all configuration items that have been considered for the implementation of the GRC Access
Control solution.
All design decisions relating to the configuration of the solution have been discussed and agreed and this
document interprets what needs to be configured and how in order for the technical solution to meet the
business requirements.

Other Reference Documentation
Details of other supporting documentation are listed below.
Document Title Version Comments
STRATA_HIGH_LEVEL_DESIGN 1
STRATA_AUTHORISATIONS_FUNCTIONAL_DESIGN 1

2. Cross Application Design
This section will detail the design of the SAP GRC Access Control (AC) cross application elements that are
independent of any Access Control module specific configuration.
Landscape
Access Control will be connected to the following target systems across the development and productive
systems. This reflects the backend SAP systems that Access Control will process user and role data for.
Connected System Access Risk Emergency Access Business Role

Analysis Access Request Management
Management Management
SAP ECC ✓
✓ ✓ ✓
SAP BW ✓
✓ ✓ ✓
SAP GRC ✓
✓ ✓ ✓
Note: Those systems that have not been included in the table above are not in scope.
Connectors
A number of communication channels (called connectors) will be created to facilitate the communication
between SAP GRC and target systems. These communicate through standard Remote Function Calls (RFC).
The RFC connections will conform to the following naming standards.
1) First three letters to indicate “System ID”

2) Next four letters to read CLNT
3) Subsequent three letters to indicate “Client ID”
For example; DE0CLNT100, where DE0 is the System ID and 100 is the “Client ID”.

The following section will outline the connections that are required and the method of connection that will be
used:
Source System Target System Connection Type
GD1CLNT100 ED2CLNT100 3
GD1CLNT100 BD2CLNT200 3
GRPCLNT200 BP2CLNT200 3
GRPCLNT200 EP2CLNT100 3
Connector Definition
Before any connectors can be used with SAP GRC, they have to be defined. The connections described
above will be defined as follows:
Target Connection Type Source Logical Port No. Background Work

Connector Connector Process
ED2CLNT100 SAP ED2CLNT100 ED2CLNT100 3
BD2CLNT200 SAP BD2CLNT200 BD2CLNT200 3
EP2CLNT100 SAP EP2CLNT100 EP2CLNT100 3
BP2CLNT200 SAP BP2CLNT200 BP2CLNT200 3
Connector Groups
Connector groups are logical groupings of physical connectors that are subject to the same SoD & critical
access rules. By grouping them together in this way the connectors will share the same set of rules and
changes made to the rules will apply to each connector.
The advantage of this approach is that rule changes will only need to be made against a logical system,
instead of against each physical connector thus reducing ongoing maintenance. Logical groupings are system
independent.

Connector Group Development Production
SAP_BAS_LG BD2CLNT200 BP2CLNT200
SAP_BAS_LG ED2CLNT100 EP2CLNT100
SAP_BAS_LG GD1CLNT100 GRPCLNT200
SAP_ECC_LG ED2CLNT100 EP2CLNT100
SAP_HR_LG ED2CLNT100 EP2CLNT100
SAP_GRC_LG GD1CLNT100 GRPCLNT200
Note: Groups ending with _LG are connector groups with logical system groupings. Groups ending
with _CG are standard connector groups.
Connector Integration Scenarios
Integration scenarios are used to define the message format, flow and exchange between two different
application components within SAP GRC Access Control which has five integration scenarios to choose from:-
AUTH (Access Risk Analysis)

SUPMG (Emergency Access Management)
ROLMG (Business Role Management)
PROV (Access Request Management)

The Strata scenarios are applicable to this implementation and all four scenarios will be assigned to all
connectors that have been defined.
Note: The assignment of all relevant scenarios to all connectors is recommended by SAP.
Connector ID AUTH SUPMG ROLMG PROV
SAP ECC ✓ ✓ ✓ ✓
SAP BW ✓ ✓ ✓ ✓
SAP GRC ✓ ✓ ✓ ✓

3. SAP GRC Plug-in
A plug-in is a piece of software that is delivered as part of the SAP GRC suite and will need to be installed to
all SAP backend/target systems that GRC is to be connected to. Plug-ins facilitates communication from the
connected system into SAP GRC. Before the plug-ins can be used with SAP GRC, a number of configuration
steps need to be completed and these will be described in the following sections.
Plug-in Parameters
Configuration parameters are set in the plug-in system to manage communication back to SAP GRC. The
plug-in parameters below will be set in each of the target systems:-
Parameter ID Parameter Description Parameter Default Value
1000 Maintenance of Plug-in Connector Connector name maintained in GRC target system
1001 Maintenance of GRC Connector
1089 Emergency Access Management Type 1
1090 Emergency Access Management Role Z_GRAC_SPM_FFID
Note: This table is cross-client, and user exit settings are transportable through the system landscape.
4. Connecting the User Data Source

The user data source defines where SAP GRC ARM will retrieve user details from for user access requests.
This section details the design decisions captured and specifics of what needs to be configured to enable the
solution according to the chosen data source.
Data Source Type Target Connector Sequence User Data Type
User Details Data EP2CLNT100 1 SU01

Source

Data Source Type Target Connector Sequence User Data Type
User Search Data EP2CLNT100 1 SU01

Source
5. Cross Module Configuration Parameters

The embedded spreadsheet below outlines all the configuration parameters that are required to service the
different modules for SAP GRC Access Control. Reference is made within the spreadsheet to what each
parameter relates to and the parameter value that will be configured.
Note: Configuration parameters for all in scope Access Control modules are included in the relevant
sections

6. Organisational Structure
The organisational structure is shared between GRC Access Control, GRC Process Control, and GRC Risk
Management. Therefore care is taken to ensure that any organisational structure implemented for Access
Control can be used in future if Process Control comes into scope.
In Access Control, the organisational structure is used to house mitigating controls.
The required organisational structure is detailed below.
Root Organisational Unit Child Organisational Unit
Strata Strata

7. Access Risk Analysis
This section will cover all related design elements for the configuration of Access Risk Analysis.
Access Risk Analysis – Configuration Parameters
The embedded spreadsheet below documents all parameters that will need to be set along with specific
values for each. These parameters will help determine the way the solution operates so that it meets business
requirements.
SoD and Critical Risk Ruleset

SoD Risks
An SoD risk always consists of two (or three or more) sides. By definition, an SoD risk occurs when a user is
able to execute multiple processes which would present an opportunity for personal gain or to misstate
financial statements. Structurally, a SoD risk in GRC consists of two or three functions (defined below). At the
risk level, the ruleset will describe how the risk may be breached (in terms of the conflicting functions) and also
provide some insight into what the risk actually is. Each SoD risk is also given a criticality rating of high,
medium or low.
Critical Risks
A critical risk always has only one side (i.e. consists of just one function). This means that a risk will be
reported if a user has access to any of the transactions in a critical function. All critical risks have the criticality
rating of critical.
The Ruleset
The SoD and critical risk ruleset is where Strata’s rules are defined in relation to what SAP transaction codes
are not permitted to be assigned to users. For SoD risks, the rules define which combinations of transactions
are not permitted. The rules also define which transactions are critical in nature in respect of potentially
compromising data confidentiality, system or data integrity or system availability.
The rules are used by Access Control to assess roles and users to identify breaches. Such breaches (conflicts
or violations) can either be found in roles (due to combinations of transactions found in a role) or at the user
level (due to combinations of roles (and thus combinations of transactions) assigned to the user).
Functions
A function in GRC terms can be defined as a task that is executed in SAP, for example purchase order
maintenance or vendor master data maintenance. A function is a wrapper in the ruleset to house all the
various transactions that could be executed by a user to run a particular task, so for example in ECC

transactions ME21N (create purchase order) and ME22N (maintain purchase order) amongst others can be
used for the task of purchase order maintenance and would therefore be found in the corresponding function.
As well as defining the transactions that a user could execute to run a task, the function will also contain a
definition of all the authorisation objects and authorisation values that are required in order to execute each
transaction. This detail is required in order to fully establish if a role or user has all the access required to be
able to execute a transaction – if they do not, then they would not be able to execute the transaction and
would thus not be able to breach the risk.
Ruleset Approach
An industry standard ruleset is delivered with GRC Access Control which contains an extensive set of SoD
and critical risks. ECC risks are defined for all end to end processes/SAP modules. Basis risks are also
included and these apply to all SAP ABAP solutions.
The SAP standard ruleset will form the basis of the Strata ruleset. During blueprint, a risk identification process
was run that has identified changes that need to be made to the SAP standard ruleset to meet Strata control
requirements. The approach to risk identification is documented below and the final Strata ruleset can be
found in full detail in the embedded ruleset file below.
Strata Rule Set
Risk Identification: Assessing SAP Standard Risks for Relevance to Strata
It is necessary to establish which particular SoD and critical risks present in the SAP standard ruleset are
relevant to Strata. Workshops were held to discuss this and establish which risks will be present in the Strata
version of the SAP standard ruleset at go-live. The line manages at Strata approved the relevant risks and
their risk level.
The overarching principle to be adopted is that SAP standard risks will be included in the Strata ruleset if there
is any suggestion that users may have access to the underlying transactions that will cause a risk. The
thinking here is that if a risk could potentially materialise, it is better to have visibility of it than not, therefore
providing Strata with opportunity to address the risk. The exception here is where risks relating to functionality
not used at Strata will be considered out of scope. These are reflected clearly in the embedded ruleset
spreadsheet above.
There is also an element of future proofing at work in this approach. Where risks are left as active where
transactions are not currently in use, there is no impact on GRC processes as risks would not be reported. In
the future, should transactions be introduced into use (either legitimately or maliciously) that would introduce
risks then no further work is required to bring GRC into line.

There are however some examples of where SAP standard risks will be out of scope for the Strata ruleset as
the functionality covered by a set of risks is not used by Strata, for example APO, CRM, and SRM. Such risks
will be set as inactive in the Strata ruleset.
Function Maintenance
SAP standard functions will be updated on a needs only basis. Generally, the SAP standard composition of
the functions will be accepted as it stands. The exceptions to this are:
1. Where custom transaction codes are identified as being relevant to an SoD risk then they will be added
to relevant functions (along with any relevant authorization objects and authorization values)
2. Where authorization values need to be updated in functions to remove a false positive
Ruleset Changes
All ruleset changes, (to functions and risks) will be managed through the standard SAP GRC workflow. These
changes should be captured and managed in the development environment and subsequently transported
through to production.
Any changes that are made to the ruleset including updates to “Functions, “Access Risks” and “Access
Controls” are recorded and time stamped.
Mitigating Controls
Mitigating Controls will be defined in the Master Data Design product after realization phase.
Business Processes and Sub Business Processes
All mitigating controls will be assigned a business process and sub business process within SAP GRC Access
Control. This is a mandatory activity to categorise the controls and this categorization activity is done upon the
creation of the control as master data. Business Process configuration will be driven by those risks that have
been activated/de-activated within the Access Controls ruleset. (embedded above)
The table below describes the business processes and sub business processes in scope:-
Business Process Sub Business Process
Procure To Pay Requisition (PR)
Procure To Pay RFP & Vendor Selection
Procure To Pay Material Planning
Procure To Pay Purchase Order (PO)

Procure To Pay Inbound Logistics
Procure To Pay Inbond Quality
Procure To Pay Supplier Quality
Procure To Pay Accounts Payable
P2P Master Data Purchasing Data (Material Master)
P2P Master Data Plant Store Data (Material Master)
P2P Master Data MRP Data - Purchasing (Material Master)
P2P Master Data Vendor Master Data - Purchasing
P2P Master Data Vendor Master Data - Finance
P2P Master Data Inspection Plans - Procured Parts
P2P Master Data Inspection Characteristics - Procured Parts
P2P Master Data Source List
P2P Master Data Info Records
P2P Master Data Cost Centers
P2P Master Data GL Accounts
Demand to Supply Production Planning

Demand to Supply Production Orders
Demand to Supply Production Orders Execution
Demand to Supply Internal Logistics
Demand to Supply Internal Quality
D2S Master Data Inspection Plans - Production Parts
D2S Master Data Inspection Characteristics - Production Parts
D2S Master Data MRP Data - Production (Material Master)
D2S Master Data Work Scheduling (Material Master)
Customer to Cash Sales
Customer to Cash Outbound Logistics
Customer to Cash Quality
Customer to Cash Accounts Receivable
C2C Master Data Inspection Plans - Finished Goods
C2C Master Data Inspection Characteristics - Finished Goods
C2C Master Data Sales Data (Material Master)
C2C Master Data Customer Master Data

C2C Master Data Customer Material Info Records
Configure to Track Engineering Data
Configure to Track Liaison Engineering
Configure to Track Tooling
Configure to Track Classification
C2T Master Data Material Master
Hire to Retire Employee Profile
Hire to Retire Organization structure
Hire to Retire Technical Qualification
Projects WBS Structure
Projects Timesheets
Document Management Document Management Sub process
Business Workplace Business Workplace Sub process
Plant Maintenance Plant Maintenance Sub process
Basis Basis Sub process
Cross Application Cross Application Sub process

Materials Management Materials Management Sub process
Finance Finance Sub process
8. Emergency Access Management

This section will cover all related design elements for the configuration of Emergency Access Management
Configuration Parameters
The embedded spreadsheet below describes the configuration parameters that are specific to the Emergency
Access Management module and documents the values that will be configured within each parameter to
enable the solution.
Reason Codes
Reason codes are set up in GRC EAM so that an emergency user self certifies the reason for why they need
to log on with enhanced access. The reason code specified is captured in the logs created by EAM and is then
used as part of the log review/challenge process which helps form the control provided by EAM. The agreed
reason codes are captured in the embedded spreadsheet below.
EAM ID Mapping
EAM users and mapping will be captured in the Master Data Design product.

9. Access Request Management
The Access Control workflow technology MSMP is based on standard SAP business workflow technology and
this enables much more flexible and tailored access request and approver views, simplifying the end to end
provisioning process.
Access Request Management automates provisioning tests for SoD issues and streamlines approvals to the
appropriate business approvers to unburden IT staff and provide a complete history of user access.
Request Types
SAP pre-delivers several standard request types. A request type is usually the first selection that is made by a
user to determine the type of access request, for example whether a request is for a new account, to change
an account or delete an account.
These standard request types represent actions that usually occur in the back end systems. The following
request types are to be defined for Strata
Type Description Detailed Description MSMP Process ID Action to Assign
1 New Account New Account SAP_GRAC_ACCE Create User

SS_REQUEST
Assign Object
2 Change Change Account SAP_GRAC_ACCE Change User

Account SS_REQUEST
Assign Object
3 Emergency Emergency User Access SAP_GRAC_ACCE Super User

User Access SS_REQUEST Access
4 Lock Account Lock Account Lock User
5 Unlock user Unlock user SAP_GRAC_ACCE Unlock User

SS_REQUEST

Access Request Priority
Access request priorities are used to determine how quickly a request should be approved or pushed through
the process. These priorities are configured and appear on the ‘Priority’ tab of the access request. The priority
level that is selected directly impacts the workflow by determining the time rate for the approval process. The
following access request priorities will be configured into the solution:-
Priority ID Description Detailed Description
High High High
Medium Medium Medium
Low Low Low
Employee Types
Employee types configured can determine the type of request and/ or workflow path that the request will take.
The following employee types will be configured.
Employee Type Description Detailed Description
1 Employees Strata Direct employees
2 Contractors Strata Contractors
Access Request Number Ranges
SAP number ranges are used to determine the request number of the access request. The request numbers
assigned under GRACREQNO in transaction code SNRO will be activated for use as shown below.

Maintain End User Personalisation (EUP)
The EUP is the screen that the end user will see/use as part of the access request. The screen can be
customised to define the behaviour of the fields and the pushbuttons on the screen.
By default, the standard SAP EUP form will be called within each access request form/stage. However, it is
possible to assign a specific EUP form to a request stage within the workflow.
The following parameters will be specified:-
Default Values: These values are automatically populated in the fields

Mandatory: A “Yes” value flags the parameter as mandatory
Editable: To allow the end user to edit the value in the selected field, this parameter must be set as
“Yes”. If the parameter is set as “No”, then the value in the field is displayed as read-only
Visible:To display the field to the end user, this parameter must be set as “Yes”
The above parameter settings apply to each access request.
The default EUP form (ID 999) settings which will be used as the base and then modified for Strata are
captured in the embedded spread sheet below:
Access Request Provisioning
GRC Access Control can be configured to provision roles and users at a global or system specific level. At the
global level, the settings that will be configured are applicable to all connected systems, unless it has been
explicitly set for a specific system. For Strata, the solution will indeed be set to system level for all role and
user provisioning.

User Defaults
A user defaults business rule can be used to define the default entries automatically maintained for a user
master record based on defined attributes and conditions in a Business Rules Framework plus application.
The user default assignment is performed on successful approval of an access request and just before
provisioning occurs in the target system. The attributes for the user default are mostly values available in
transaction code SU01 (User Maintenance). Additionally, user group assignment and parameter IDs to be
provisioned can be maintained by default based on a defined business rule.
This capability provides control to access provisioning, saves time in maintaining numerous master records,
and makes the assignment of SU01 specific values less error prone. A number of fields in the user master
data can benefit from user default assignment.
Once the user defaults have been configured, the data is transferred to the appropriate SAP backend system
(in transaction code SU01) as defaults.
The following table defaults will be configured for the Strata in accordance with client discussions.
User Default Description User Type 1 User Type 2
spool spool LOCL Output Immediately
Decimal Notation Decimal Notation 1,234,567.89
Date Format Date Format DD.MM.YYYY
Sys. Time Zone Sys. Time Zone UTC+4
Parameter ID’s
The following parameter ids will be set for users.
Parameter ID System User Type 1 User Type 2
<insert> <insert> <insert> <insert>

Parameter ID System User Type 1 User Type 2
Once the default values and parameter ids have been confirmed the following BRF+ rule will be configured.
The user defaults functionality works on the principle that the BRF+ application evaluates a series of input
criteria and then outputs a specific result value. This result value then equates to the key assigned to the
specific user default configuration set in customizing (user default master data). The first step in setting up a
user defaults business rule is to identify the attributes for which it is intended to maintain user defaults. These
records typically exist in transaction code SU01.
Business Roles
Business roles will be configured according to the business roles mapping matrix that will be provided as part
of the role mapping exercise. This section will be updated with the business role map once this has been
approved.
Access Request Management – Configuration Parameters
The parameters specified in the embedded spreadsheet below will be configured into ARM in order to enable
the solution:-
Workflow Design and Configuration

Access Control Workflow Capability
SAP provide a number of “out of the box” workflow processes for SAP GRC Access Control. Whilst additional
and customised Multi Stage Multi Path (MSMP) workflow processes cannot be created, it should be noted that
the delivered workflow processes are sufficient for leveraging all possible GRC Access Control capabilities.
All MSMP workflow processes are fully modifiable, allowing dynamic workflows to be designed and
implemented. The addition of Business Rules Framework (BRF+) allows the implementation of custom
initiators, approver stages and detour routes.
In the latest ABAP based technology, it is expected that the system performance will be more robust than
older product versions, therefore giving a reliable and fast user experience.

A number of settings can be applied within the workflow approval stages to cater for different approver types
or specific stage behaviours, such as enforcing SoD checks or the mandatory inserting of comments prior to
request approval. BRF+ will be leveraged where required.
The table below outlines the workflow processes that are delivered by SAP. In scope ARM workflow
processes will be modified and configured to meet solution requirements.
SAP Standard Workflow Processes
Process ID Description Module Notes In Scope
SAP_GRAC_ACCESS_REQU Access Request ARM General Access Request Management YES

EST Approval process.
Workflow
SAP_GRAC_ACCESS_REQU Access Request ARM HR based Access Request process NO

EST_HR Approval
Workflow for HR
OM Objects
SAP_GRAC_CONTROL_ASG Control ARA Initiates a workflow item to approve YES

N Assignment Mitigating Control assignments.
Approval
Workflow
SAP_GRAC_CONTROL_MAI Mitigation Control ARA Workflow to approve changes to YES

NT Maintenance Mitigating Control definitions. Mitigation
Workflow controls are independent to the ruleset
and maintained as master data on each
instance of GRC v10.0.
SAP_GRAC_FIREFIGHT_LO Firefighter Log EAM Initiates a workflow item containing the YES
G_REPORT Report Review EAM session log to review and approve.
Workflow

Process ID Description Module Notes In Scope
Workflow item sent to the EAM Controller.
SAP_GRAC_FUNC_APPR Function Approval ARA Initiates approval request for proposed YES
Workflow changes to Ruleset Function definitions.
NOTE: This workflow should only be

enabled within the GRC 10.0
Development system
SAP_GRAC_RISK_APPR Risk Approval ARA Initiates approval request for proposed YES
Workflow changes to Ruleset Risk definitions.

enabled within the GRC Development
system
SAP_GRAC_ROLE_APPR Role Approval BRM The Role Build/Maintenance workflow. YES

Workflow
enabled within the GRC Production
system, but the Role
Build/Maintenance should take place
against the Development target
system.
SAP_GRAC_SOD_RISK_RE SoD Risk Review ARM / The SoD review is a workflow process to YES
VIEW Workflow ARA initiate and route periodic SoD Risk
Reviews, where a review is conducted
upon the overall access related risks
within the landscape by business
managers and/or risk owners. This
MSMP process can also be configured to
initiate the removal of violating roles via
Access Request Workflow.<period>
SAP_GRAC_USER_ACCESS User Access ARA / The User Access Review is a workflow YES
_REVIEW Review Workflow ARM process to initiate and route a periodic
User Access Review, where a review is
conducted upon the user access within
the landscape by business managers or
role owners.<period BRM data, must
configure BRM correctly>

Access Request Process
Workflows will be created by modifying the delivered SAP_GRAC_ACCESS_REQUEST MSMP workflow

processes. The requirement of enforcing SoD/critical risk analysis on the Access Request shall also be
enabled.
Custom Approval Agents
Whilst GRC provides ready to use agent rules such as “Role Owners” and “EAM ID Owners”, the application
does not provide all the necessary agent types by default. Therefore, custom agents can be created to act as
approvers or be notified of any event within the access request workflow. There are four methods of being
able to define who the agent would be as follows:-
1. Directly Mapped Users – Allows to be defined as a static user group (i.e. directly listed within
the GRC workflow)
2. PFCG Roles – Recipient identified via an active role assignment within the GRC system
3. PFCG User Groups – Determined on a user group assignment within the GRC system
4. GRC API Rules – Coded as per rule’s type i.e. BRF+ rule, ABAP Class based rules (usually
SAP delivered) or Function Module Based Rules
The Custom Agents not be configured at this time on this greenfield implementation at Strata.:-
Access Request Initiator
An MSMP process ID can have only one Initiator assigned for use, therefore all Initiator results must be listed
out within the custom BRF+ table with the results for the required path. The result shall be determined by the
attributes within the request e.g. User Group, Business Process, System, Request type etc.
The Role Types/ Critical Level / Company/ Functional Area attributes designated to a role definition will
determine the result of the Access Request initiator. The attributes are assigned to the role definitions in the
GRC AC BRM tool.
Initiator Result Result Request Type

Description
DLU Lock, Unlock 3, 4 & 5

and Delete
EAM Super User 006

Request
NC New and 01 and 02

Change
Paths and Stages
Each workflow is made up of a number of stages (refer below section) and the workflow path determines the
sequence in which these stages take place.

There is a one for one relationship between the Initiator result and the Workflow Paths (therefore each
Workflow Path is assigned one of the above Initiator results and has the same name) with the exception of the
Detour Path for No Role Owner. This path handles requests with no roles or those that have roles with no
owners and therefore does not have a specific Initiator.
The following table details the required Workflow Paths:-
Path Name Path Description Initiator Result No. Of Stages
GRAC_DEFAULT_PATH Default Path NC 3
LOCK_UNLOCK_DELETE LOCK_UNLOCK_DELETE DLU 1
EAM EAM EAM 1
SOD REVIEW STAGE SOD REVIEW STAGE SODVIOL_DETOUR_PATH 3
There are one or more stages in a workflow path. At each stage the workflow will determine the appropriate
approver for that stage (based on the criteria set for that specific stage) and route the work item to them for
action.
Within this section it is also necessary to specify the wait time and escalation configuration for the details of
the values to be populated for each stage, along with the justification for these options. For each stage the
notification and additional configuration must be completed.
The embedded spreadsheet below contains a table documenting the stages that have been defined. The
standard/custom Agent Rules to be assigned to the individual stages have been specified also. The stage
settings also determine if the performance of a Risk Analysis is mandatory by the approver.
Escape Route
The Escape Route will be initiated for example when an approver rejects all roles in a request and
consequently there are no roles remaining to approve in the next stage. The Request will escape route to the
No Role Owner Approver to be rejected by the appropriate team.
Notifications
Each stage has specific notification settings configured to notify the necessary involved individuals/groups of
decisions made. The table below shows under which circumstances a user will receive a notification from the
system during the workflow process.

Stage Notification User Requestor Manager Other Approvers
Manager Approved x X X
Escalated x X X
Rejected x x X

Submit x
Role Owner Approved x X X
Escalated x X X
Rejected x x X

Submit x
 
Security Approved
Escalated
Rejected X X

Submit x
Provisioning
ARM enables users and roles to be provisioned automatically to SAP systems upon completion of the
approval stages in the workflow. Alternatively, the information and approvals can be collected and used by
Administrators to manually update the system. SAP production systems will be provisioned automatically to
the user master record.

The following sections define the request types and workflow processes that will be implemented in order to
satisfy the business requirements.
New Users
Path Name Path Description Initiator Result
GRAC_DEFAULT_PATH Default Path NC
Change User Access
GRAC_DEFAULT_PATH Default Path NC
No Role Owner
ESCAPE PATH ESCAPE PATH ZINIT_RULE
If a request is submitted or approved that contains no roles to approve, or if a New User or Change User
request contains no roles, then the request cannot be processed. Rather than creating an error in the system,
an escape route workflow is to be configured to send these requests to a central team for review and rejection.

These workflows do not have a specific initiator result; however a path must be configured with valid stages.
Lock User
Path Name Path Description Initiator
LOCK_UNLOCK LOCK_UNLOCK ZINIT_RULE
Unlock User
Path Name Path Description Initiator
LOCK_UNLOCK_DELETE LOCK_UNLOCK_DELETE ZINIT_RULE
Request Access to an Existing FireFighter ID
EAM EAM ZINIT_RULE
This workflow deals with requests for an existing SAP user to have access to an existing EAM User ID. This is
not to request a new EAM User ID to be created.
Only valid EAM ID’s (existing within the target system) can be requested for users who have access to the
EAM cockpit within the GRC system itself.
Embedded Risk Analysis
A request containing SAP access shall be subjected to an automatic risk analysis upon submission. This will
ensure the approver receives the request with any potential risk violations reported prior to approval.

Access Risk Analysis Maintenance
Various MSMP workflows are available as default to enable audited maintenance of the Access Risk Analysis
ruleset and control definition and assignment.
By default, these requests do not need initiators to be maintained. However it is recommended that the ruleset
maintenance related workflows are only activated and initiated from the GRC Development systems; as SAP
best practice is to maintain the ruleset within GRC Development only and transport the changes across the
rest of the landscape.
It should be noted, as the standard workflows provided by SAP are being utilised for ruleset maintenance,
custom initiators and custom paths do not need to be created or maintained.
Control Assignment Approval Workflow
This workflow initiates a request item to the designated Control Owner to approve an assignment of a
Mitigating Control to a user. This request can be initiated during the process of applying a Mitigating Control to
a user manually or during the Access Request workflow process.
By default the MSMP process (SAP_GRAC_CONTROL_ASGN) uses a single stage approval process. This
shall not be altered for Strata. It is recommended to enable this MSMP process within the GRC Production
system for live use.

Mitigation Control Maintenance Workflow
The Control Maintenance workflow process (SAP_GRAC_CONTROL_MAINT) initiates a workflow item to

approve changes to a Control Definition, including associated control reports. Mitigating controls are
independent to the GRC Risk Ruleset and maintained as master data independently on each GRC instance.
By default, the MSMP process uses a single stage approval process. It is recommended to enable this MSMP
process within the Production system for “live” use.
Function Approval Workflow
The MSMP process SAP_GRAC_FUNC_APPR initiates an approval request for proposed changes to ruleset
Function definitions. By default the process consists of a single stage approval.
This workflow should only be enabled within the Access Control Development system as ruleset changes
should be executed in the development system and transported across the landscape.

Risk Approval Workflow
The MSMP process SAP_GRAC_RISK_APPR allows changes within a risk definition to be reviewed and
approved by the designated approver (by default the Risk Owner) prior to the ruleset being regenerated taking
the changes into account.
This workflow should only be enabled within the Access Control Development system, with approved changes
being transported across the landscape.
Emergency Access Workflow
Access Control provides the capability of managing the assignment of EAM ID’s to users via the Access
Request process. In addition, there is an Emergency Log review to be conducted via automated workflows
being sent to the designated EAM ID Controller.
It should be noted, as the standard workflows provided by SAP are being utilised for receiving and reviewing
the EAM session log reports, custom initiators and custom paths do not require to created or maintained.
FireFighter Log Report Review Workflow
The Controller must be set to receive logs via “Workflow” for the specific EAM ID. This will be set-up in the
front end of the GRC system. Once an emergency session has been concluded, the GRC system initiates a
workflow via the SAP_GRAC_FIREFIGHT_LOG_REPORT MSMP process containing the EAM session log to
review/approve.
By default, this process consists of a single stage approval process and ensures the Emergency logs are
being audited in a timely manner.

Reminder emails shall be sent to controllers who have not reviewed the logs in a timely manner and shall be
escalated to the Emergency ID Owners.
Business Role Management workflow
In order to use BRM, the methodology processes and steps for role maintenance need to be defined. The
application provides a set of actions that can be used for role maintenance, such as Definition, Actions &
Permissions, Risk analysis, Derive, Approval, Generation, Testing and Provisioning (only for Business Roles).
Users can select which actions to use, the order, and the frequency per methodology created.
It should be noted, as the standard workflows provided by SAP are being utilised for notifying the role owner/s
and accepting the approval for the new/changed role definition, custom initiators and custom paths do not
need to created or maintained.
Role Content Approval
The approval action results in an approval request being sent to the assigned Role Owner/s to approve the
creation/content update of the role definition. This functionality utilises the MSMP workflow process
SAP_GRAC_ROLE_APPR.
By default, the process uses a single stage approval process. This shall not be altered for Strata. This MSMP
process will be activated within the GRC Production system for live use, with the actual role build and
maintenance taking place against the target Development system. Once the role has been approved and
generated, it shall be transported across the rest of the landscape as per existing processes.

Email Notification Templates
Each workflow event in the Access Control workflow process can trigger an email notification that corresponds
to exactly one pre-defined message class. Each message class corresponds to one document object
containing a pre-delivered message body for the respective workflow event.
The workflow events are:
New Work Item: send to the inbox of the responsible approver(s)

Approval: approval of request or line item
Rejection: rejection of request or line item
Escalation: escalation of request
Upon a request submission and at the end of a request, notifications are sent to notify the user of the
beginning and end of the process respectively.
The table below lists each process ID or event and the corresponding message class for each one of the
workflow events that are required by Strata:-
Process ID\ Event New Work Item Approved Rejected Escalated
SAP_GRAC_ACCESS_REQUES 0MSMP_AR_ 0MSMP_AR_ 0MSMP_AR_ 0MSMP_AR_

T NEWWORKITM APPROVED REJECTED ESCALATION
SAP_GRAC_FIREFIGHT_LOG_R 0MSMP_LOGRPT 0MSMP_LOGRPT 0MSMP_LOGRPT 0MSMP_LOGRPT

EPORT _ NEWWI _ APPR _ REJC _ ESCL
SAP_GRAC_RISK_APPR 0MSMP_RISK_ 0MSMP_RISK_ 0MSMP_RISK_ 0MSMP_RISK_

NEWWI APPR REJC ESCL
SAP_GRAC_ROLE_APPR 0MSMP_ROLEAP 0MSMP_ROLEAP 0MSMP_ROLEAP 0MSMP_ROLEAP

Process ID\ Event New Work Item Approved Rejected Escalated
PR_ NEWWI PR_ APPR PR_ REJC PR_ ESCL
SAP_GRAC_SOD_RISK_REVIE N/A 0MSMP_RISKRE 0MSMP_RISKRE 0MSMP_RISKRE

W VW_ APPR VW_ REJC VW_ ESCL
SAP_GRAC_USER_ACCESS_R 0MSMP_USERA 0MSMP_USERA 0MSMP_USERA 0MSMP_USERA

EVIEW CC_ NEWWI CC_ APPR CC_ REJC CC_ ESCL
SAP_GRAC_ACCESS_REQUEST comes with the following additional events and message classes:-
Request submission: 0AC_AR_SUBMIT (sent to affected user)

Request approval by Mail: 0MSMP_AR_APP_REJ (sent to approver alternatively to message class
0MSMP_AR_NEWWORKITM)
Request forwarded: 0MSMP_AR_FORWARD (sent to approver(s) who the request was forwarded to)
Request closed (completed): 0AC_AR_CLOSE (sent to affected user)
Email Reminder: 0MSMP_EMAILRMDR_CUP (sent to responsible approver(s))
The SoD Risk Review workflow comes with two additional message classes for email reminder events. These
are:-
0MSMP_EMAILRMDR_SOD (sent to responsible approver(s))

0MSMP_EMAILRMDR (sent to responsible approver(s))
The content of each document can be maintained via SE61.
Authentication to SAP GRC and Target Systems

Password Self Service
Password Self Service functionality allows end-users to reset their passwords in the SAP backend system
without having the SAP Help Desk or the SAP Security Group involved. This tool saves the SAP Security
Group time and expedites the password resetting process for the end-user.

10. Business Role Management
Business Role Management – Configuration Parameters
The parameters that need to be maintained to facilitate the BRM solution are captured in the embedded
spreadsheet below along with the required values.
All role information that is to be used within ARM and BRM for end user provisioning is now maintained in
BRM.
Business Processes and Sub Business Processes
In BRM, business process and sub business processes are attributes that are assigned to the role definition.
This helps categorise roles in a way that is easier for end users to navigate and select roles when creating
access requests. This is also used to drive the ARM workflows. These are the same business processes that
are configured for ARA.
Note: To register and define roles for ARM and BRM, a sub-process will need to be selected and
assigned along with its corresponding business process.
Role Types
A number of SAP role types are pre-delivered with GRC Access Control. Role types that are marked in
configuration are in-active for ARM and BRM modules. By default, all role types are set as active and some of
these will need to be de-activated for Strata. The following role types shall be made in-active.
Note: GRC 10.0 will support the provisioning of ABAP and JAVA roles as part of the provisioning
processes

An additional and optional feature for role types is the ability to define the maximum character length that is
required for the name of the role. For example, a single ABAP role in SAP can have a maximum of 32
characters. This should be specified here. If the role naming convention suggests the character length should
be 30 characters, then 32 should be replaced with 30.
This feature is useful for integration with other systems that may have such character length limits:-
Note: New role types cannot be added.
Companies Definition
Roles can also be categorised and/ or assigned to Strata (1000), Strata Manufacturing, Al Ain, UAE.
Functional Areas
The functional area values will be used to route the divisional approval of user requests (via BRF+ rule based
custom agents). The functional areas are based on user groups however they are a separate (role attribute)
entity within ARM.
The functional areas documented in the embedded spreadsheet below will be created:-
Default Roles
Default roles are roles that are assigned to user requests under certain access request conditions. For
example, if a new user is created for ECC and a set of two default roles is required as a basis to navigate
SAP. These roles are known as “default roles”.
Default roles can be configured in Access Control so that they are added to an access request according to
the request attributes selected by the requester.
The table below outlines the default roles that have been identified as necessary. These or equivalent roles
will be configured in the solution as default roles:-

Attribute Attribute Value Role Name System
<insert> <insert> ZS_XX_EMPLOYEE EP2CLNT100
<insert> <insert> ZS_XX_EMPLOYEE ED2CLNT100

11. Appendix One: Background Jobs
This appendix describes the setup of GRC Access Control jobs that are run to synchronise the plug-in systems
with GRC. Various data requires to be synchronised from the client systems with the GRC instance using
various transactions. These programs can also be maintained as scheduled background jobs.
A number of jobs are scheduled and will be subject to review once system performance has been factored in.
Authorisation Data Synchronisation
This background job synchronises the authorisation object information from PFCG into the SAP GRC
repository. The input parameters will be as follows:-
Background Job Parameter Parameter Value
System Field *
Language EN
Repository Object Synchronisation
This background job synchronises the role profiles, role names and user master information into the SAP GRC
repository. Depending on the selections, the program executes 3 other programs. It can be executed in full
mode (Synchronises all data, as of 01/01/1970 until current date) or incremental mode (checks changes since
last execution of program).
The input parameters will be as follows:-
Select Sync Job Profile / Role / User
Language EN
Sync Mode Incremental / Full
Transaction Usage
This background job synchronises user transaction usage counts into the SAP GRC repository. This retrieves
data from the standard SAP monitoring tables from within the plug-in systems. The input parameters for the
job are:-

Connector *
User *
Roles Usage
This background job synchronises the role usage count for users into the SAP GRC repository. The settings
for the job are:-
Connector *
Language EN
Batch Risk Analysis
This background job populates the SAP GRC Access Control dashboards/management reports. It uses a
combination of offline tables that drive and update information on a periodic basis.
Emergency Access Management Logs
This background job retrieves emergency access management activity from plug-in systems. This data is then
consolidated and used to populate the log files that are centrally accessed through SAP GRC.
Connector ED2CLNT100
Connector BD2CLNT200
Connector BP2CLNT200
Connector EP2CLNT100
Note: Ensure the EAM log synchronisation job is setup with the connector id set to the system name
and not “*”.

Reminder Email Notifications
SAP GRC is pre-delivered with two templates that can be used for periodic email reminders and notifications
for each workflow process. These are shown below:-
Email Template Template Description
GRAC_EMAILRMDR_CUP Used for Access Request Approval workflows
GRAC_EMAILRMDR_SOD Used for SoD Risk Review Workflow
Custom document objects containing customized message bodies for these template IDs (message classes)
can be created.
The table below shows all synchronisation jobs and their recommended frequency.
Note: The jobs all need to be run and scheduled separately on the Development and Production instances of
Access Control.
Background Job Job Name Full / Incremental Frequency Variant
Full Repository GRAC_REP_OBJ_SYNC_FULL Full Weekly GRC_OBJSYNC_FL

Synchronisation
Incremental GRAC_REP_OBJ_SYNC_INC Incremental Hourly GRC_OBJSYNC_IC

Repository
Synchronisation
Action Usage Sync GRAC_ACT_USAGE_SYNC N/A Daily ALL_ACT_USAGE
Role Usage Sync GRAC_ROLE_USAGE_SYNC N/A Daily ALL_ROLE_USAGE
Batch Risk GRAC_BATCH_RISK_ANALYSIS_FU Full Monthly GRAC_BRA_FULL

Analysis LL

Background Job Job Name Full / Incremental Frequency Variant
Batch Risk GRAC_BATCH_RISK_ANALYSIS_IN Incremental Daily GRAC_BRA_INC

Analysis C
EAM Log Sync GRAC_SPM_LOG_SYNC_UPDATE N/A Hourly EAM_LOG_SYNC
Authorisation Sync GRAC_AUTH_SYNC N/A Monthly GRC_AUTH_SYNC
Access Request GRFNMW_BATCH_EMAIL_REMINDE N/A Hourly GRFNMW_BATCH_

Approval Workflow R_CUP EMAIL_REMINDER

2-4-0 Acr1 Detailed Level Design 1-Rev2

Uploaded by

Copyright:

Available Formats

2-4-0 Acr1 Detailed Level Design 1-Rev2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2-4-0 Acr1 Detailed Level Design 1-Rev2

Uploaded by

Copyright:

Available Formats

Access Control Product:

Detailed Level Design

Documenting the detailed solution design; capturing

Author(s): Fahri Batur

Issue Date: 4th November 2013

Contact: Fahri Batur

2. Cross Application Design.........................................................................................................5

3. SAP GRC Plug-in.......................................................................................................................9

4. Connecting the User Data Source.........................................................................................12

5. Cross Module Configuration Parameters..............................................................................15

7. Access Risk Analysis............................................................................................................. 17

8. Emergency Access Management.......................................................................................... 20

9. Access Request Management................................................................................................21

10. Business Role Management...................................................................................................28

11. Appendix One: Background Jobs......................................................................................... 31

2. Detailed Level Design www.integrc.com

Integrc: Version 1.0

Document Change Control

Date Version Author Changes

4th November 2013 1.0 Fahri Batur Initial version

3. Detailed Level Design www.integrc.com

Document Title Version Comments

4. Detailed Level Design www.integrc.com

Connected System Access Risk Emergency Access Business Role

The RFC connections will conform to the following naming standards.

1) First three letters to indicate “System ID”

5. Detailed Level Design www.integrc.com

Source System Target System Connection Type

Target Connection Type Source Logical Port No. Background Work

ED2CLNT100 SAP ED2CLNT100 ED2CLNT100 3

BD2CLNT200 SAP BD2CLNT200 BD2CLNT200 3

EP2CLNT100 SAP EP2CLNT100 EP2CLNT100 3

BP2CLNT200 SAP BP2CLNT200 BP2CLNT200 3

6. Detailed Level Design www.integrc.com

SAP_BAS_LG BD2CLNT200 BP2CLNT200

SAP_BAS_LG ED2CLNT100 EP2CLNT100

SAP_BAS_LG GD1CLNT100 GRPCLNT200

SAP_ECC_LG ED2CLNT100 EP2CLNT100

SAP_HR_LG ED2CLNT100 EP2CLNT100

SAP_GRC_LG GD1CLNT100 GRPCLNT200

Connector Integration Scenarios

AUTH (Access Risk Analysis)

7. Detailed Level Design www.integrc.com

Connector ID AUTH SUPMG ROLMG PROV

8. Detailed Level Design www.integrc.com

Parameter ID Parameter Description Parameter Default Value

1001 Maintenance of GRC Connector

1089 Emergency Access Management Type 1

1090 Emergency Access Management Role Z_GRAC_SPM_FFID

4. Connecting the User Data Source

Data Source Type Target Connector Sequence User Data Type

User Details Data EP2CLNT100 1 SU01

9. Detailed Level Design www.integrc.com

User Search Data EP2CLNT100 1 SU01

5. Cross Module Configuration Parameters

10. Detailed Level Design www.integrc.com

In Access Control, the organisational structure is used to house mitigating controls.

The required organisational structure is detailed below.

Root Organisational Unit Child Organisational Unit