The SAP Access Control supplemental rule is a functionality that eliminates false positives and provides additional information to identify segregation of duties (SoD) violations. It performs a check with the database table and field name and works to prevent having a false conflict reported as a SoD violation.

It identifies users who are allowed to perform a transaction, but are prevented from doing so by a false report. A false positive scenario in risk analysis wrongly indicates that the user could perform a fraudulent transaction with the given authorization access. For example, Akansha is a user who can run transaction code SU01 (Create User or Assign Role) anytime, which can be identified as a false positive risk. To check that false positive risk, the system does a further check to the database table that eliminates it.

A false positive can occur on the basis of a rule set. A rule set is a collection of rules generated from risks. The system performs an additional check against an SAP table to identify and help to remove those false reports of conflict violations. The table resides in the SAP ERP plug-in system. The additional check logic is known as a supplementary rule.

An employee’s responsibilities and rights are treated as user actions and permissions in a plug-in system. The object level Access Risk Analysis (ARA) reports are further analyzed by performing a check with the database table and field name. There are two such SAP database tables: USR02 and AGR_USERS. The flow chart in Figure 1 explains the use of the tables.

Figure 1

Use of a database table in a supplemental rule and supplemenary risk analysis

To log on to the SAP ERP plug-in system use transaction code SE11 and follow menu path Database table > USR02. This table contains all logon user information with the user name, user type, and from and to date.

To see table AGR_USERS log on to the SAP ERP plug-in system using transaction code SE11. Follow menu path Database table > AGR_USERS. This table contains all users who have a role with their profile. The user ID, associated role name, from and to date, and changed date information are maintained in this table.

A supplementary rule is always defined on an SAP database table. The supplementary rule does an additional check on that table. For example, table USR02 has information about user ID Akansha. The ABAP system with the GRCFND_A installed component is an ARA tool.

I include the following sections in this article:

• A business scenario with an example of access restrictions
• SPRO configuration settings
• Steps to create supplementary rules

A Business Scenario with an Example of Access Restrictions

Authorization is a kind of permission given to a user to perform a task. Authorization is an instance of an authorization object that is a combination of allowed values for the authorization field of the authorization object. Authorizations are granted to users (objects) to create/generate, change, display, delete, activate, post, release and update activities (ACTVT). The ACTVT field values are stored in database table TACT in an SAP ERP system.

These activities are checked in the SoD object level risk analysis to eliminate false positive risks. A false positive risk report is a combination of actions and permissions that do not show up in an SAP Access Control risk analysis report on the transaction level. When you run an SAP Access Control risk analysis report at the Action level and Permission level, the Action level risk analysis is based on transactions.

For example, Action level reports check SU01 and SE28 actions or transactions. The Permission level risk analysis is based on an authorizations object such as Action SU01 with Activity 03 (Display). The object level risk analysis shows conflicts in risk analysis reports. Positive refers to a transaction or action that has not been executed by a user, but causes a SoD conflict in the risk analysis report. Supplementary rules provide an additional filter during risk analysis. Here SU01 and SE38 are transactions or actions.

My example company uses a field value called Permission to restrict order approvals. To set up this value, execute transaction code CO01 and follow menu path Setup > Access Rule Maintenance > Quick Links > Functions >SOD Function > Create. This path takes you to the screen shown in Figure 2.

Figure 2

The Action tab in Access Control

You see two tabs, Action and Permission, and a Save button to save data. The Action tab contains transaction details, and the Permission tab contains the transaction’s permissions details. Permissions are defined in Figure 3.

To go to Figure 3 follow menu path Setup > Access Rule Maintenance > Quick Links > Functions > SOD Function > Create. Ruleset maintenance includes maintaining functions with actions and permissions.

Figure 3

The Permission tab

The Permission tab contains detailed information in a new function view. Permissions must be in Active status to do Permission level risk analysis. There is a drop-down in the Status column with two values: Active and Inactive. To make it active, select the Active drop-down choice. Next you need to assign permission and field values to users for Permission Group CO01. Follow menu path transaction NWBC > cockpit nwbc > Setup > Access Rule Maintenance > Quick Links > Functions > SOD Function > Create.

Enter the Function ID, Business Process, and Analysis Scope. Go to the Action tab in the view and assign action CO01. Then click the Permission tab. The Permission tab’s fields are automatically populated with authorization objects that by default are in Inactive status. By default all objects are in Active status in the Action tab and Inactive in the Permission tab. This is the reason the Active drop-down is selected in the Action tab.

Now you create a role name by logging on to the ERP plug-in system. Execute transaction code PFCG and follow menu path Create a role name SUP_ROLE2 > authorization. In this case the system identifies two users with a conflict. Only one of two users has permission to release orders greater than $5,000. Users with permission to release orders must be provided transactional access through security roles.

Tracking Risks with ARA
ARA is a reporting tool to identify a risk at the user, role, or profile level. An ARA report shows the number of conflicts. There are three types of risk: SoD, critical action, and critical permission.

A SoD risk has at least two functions. For example, function SUP_FUN1 is a function ID and user-defined description associated with actions. Functions should have two actions. Action is a transaction code or command that takes you to a screen. For example, the SU01 and PFCG actions execute in the ERP plug-in system. SoD risks are of two types — one is Action Level and the other is Permission Level. These are risk analysis types for action and permission risks. ARA at the Action Level risk type checks actions in conflicts, such as SU01 and PFCG. Actions SU01 and PFCG with Activity 01 (Create/Generate) check on permission level risk types with actions and permissions.

The two functions are a grouping of one or more related actions or permissions for a specific business process. A business process is a category of a business area in which you want to report ARA results in ARA and remediation. For example, Finance, HR, Basis, and procedure to payment are the business processes as are salaryslip and tax deductions.

Action level risk analysis only compares rules at the transaction level, whereas permission level risk analysis further filters the results based on the authorization objects. Authorization objects associated with transaction code SU53 are transactions to get authorization objects for a user.

A user requires authorization not only to execute the risk analysis tool but also to be permitted to run SAP Access Control functionality. For example, a user has authorization to run a risk analysis tool; however, when the user tries to create a supplementary rule, the user receives an error message saying “you are not permitted to perform this action.”

That means that an authorization object (GRAC_SUPP) for a supplementary rule did not provide a user’s authorization checks with transaction code SU53. Figure A shows the SU53 authorization view. For example, SU53 shows that a user GUPTAAKA is missing an authorization. S_TCODE is an authorization object at the start transaction and TCD is the authorization field. The Authorization field contains a value – for example, a transaction code.

Figure A

An example of authorization data for user GUPTAAKA

A critical action risk has only one function, and the function must have only one action. A function is a grouping of one or more related actions or permissions. An action is an activity that is performed in the system in order to fulfill a specific function, for example, CO01. Critical means only one transaction or action must be assigned. For a critical action risk there should be only one function defined.

A critical permission risk has only one function, and the function must have only one permission. There is no action defined for critical permission. Permissions and authorizations are the same. You need to create a Permission using the Function tab. Then you create the function, but do not create an action or a transaction in the function.

There is only one function assigned to create a critical permission risk. Authorizations and permissions are the same because user authorizations in the plug-in system appear in the Permission tab of the function view. Figure B shows the meaning of no action. It shows that when you need to create a function for a critical permission risk, there should not be any action. The Action tab must be blank. It is called No Action in the Action tab.

Figure B

There is No Action to create a critical permission

SPRO Configuration Settings

Transaction code SPRO is used to set up and configure SAP Access Control. Log on to the ABAP client for GRC and run transaction SPRO. The main purpose is to check if GRCFND_A (GRC software package) is installed and to open the SAP Access Control application in the ERP system. Then navigate to the next screen in the GRC back-end system in the IMG by pressing Enter. This action takes you to Figure 4.

Figure 4

Reference IMG view

The IMG is a tool for configuring (customizing) a single SAP system. The customizing activities and their documentation are structured from a functional perspective. (To configure a whole system landscape from a process-oriented perspective, use SAP Solution Manager, which handles the relevant customizing activities in the individual SAP systems.)   

In Figure 4 click the SAP Reference IMG button to go to the next screen with the heading Display IMG. Follow menu path Governance, Risk and Compliance > Access Control on the Display IMG screen, which takes you to the SAP Access Control 10.x application. You also can navigate to IMG > Governance, Risk and Compliance > Access Control in the ABAP Client system, which also takes you to the SAP Access Control 10.x functionality. The ABAP Client system must have the GRCFND_A software package installed. If the GRCFND_A software package is installed on the ABAP client system, then the Governance, Risk and Compliance node is visible on the IMG.

Click the IMG Information button in Figure 4 and then click Governance, Risk, and Compliance > Access Control > Maintain Configuration Settings. The view has all the configuration parameters. The parameters in Figure 5 are two of them.

Figure 5

GRC configuration settings parameters with parameter values

Figure 5 shows the supplementary rule and offline analysis configuration setting to get supplementary risk analysis results. SAP Access Control 10.0 and 10.1 both have the same parameters in the configuration setting.

Risk analysis Parameter 1037 and 1027 must be YES and NO, respectively. To consider a supplemental rule in SAP Access Control risk analysis, Parameter 1037 has to be set to YES.

Parameter 1038 should be NO because the risk analysis results in access management such as User level, Role level, and Profile level are based on real-time risk analysis that is called online risk analysis.

Steps to Create Supplementary Rules

You take the following steps to create a supplementary rule in SAP Access Control 10.0 and 10.1.

Step 1. Log on to the ABAP client for GRC by executing transaction NWBC > cockpit nwbc. Click the NWBC hyperlink.

Step 2. This step helps you to get the Supplemental Rules hyperlink and to reach the Supplemental Rules Create button functionality in the SAP Access Control application. Execute transaction NWBC and follow menu path Setup > Exception Access Rules > Quick Links > Supplemental Rules. Figure 6 shows how to reach a supplementary rule on an SAP Access Control application. (Supplemental rules is the term used in SAP Access Control 10.0 and supplementary rules is used in SAP Access Control 10.1, but there is no difference in functionality.) Click the Supplementary Rules button to go to Figure 7.

Figure 6

Access Control Supplementary Rules hyperlink

In Figure 7 click the Create button to open Figure 8.

Figure 7

Create a new supplementary rule

In Figure 8 after populating the required fields, you click the Save button to save a new supplementary rule.

Figure 8

Save the new supplementary rule

To create a supplementary rule, populate the following fields shown in Figure 8:

• System: System is the plug-in system where the user, role, and action are defined.
• Access Risk ID: A supplementary rule always has a SoD risk. A Risk ID is a combination of two or more actions or permissions that are assigned to a single user (employee of an organization).
• Function ID: A unique identification function ID that has one or more transaction codes that an employee needs to perform a specific goal.
• Table Name: AGR_USERS is a table name in an SAP NetWeaver system or SAP ERP Central Component (ECC) 6.0 system.
• Check Field Name: For example, UNAME is a field name of table AGR_USERS. The field’s name is either UNAME or BNAME. UNAME is a user name, and BNAME is the user name in the user master record where you check for user violations.
• Include Violations is a drop-down field to create a supplementary rule. The Include Violations field has two options, Yes and No. It checks whether SoD conflicts should be considered or not. Select Yes if a supplementary rule is satisfied for a user and the supplementary risk analysis report shows SoD conflicts. Those users who meet the SoD rule criteria and the supplemental criteria are included in the report if the drop-down value is Yes. The report excludes users who meet the criteria of the supplemental check if the drop-down is No and then no violations appear in supplementary risk analysis.
• Field Name: This field is for is the user who has some conflicts in executing actions. Just as AGR_USERS is a table in the back-end plug-in system, AGR_NAME is a field name in table AGR_USERS. In this case the user is an object that behaves as an employee in an organization.
• Field Value: A user has some roles. Logically the Field Value is a value of a CHECK FIELD NAME. A Check Field name is a field or column name of a database table (e.g., the UNAME is a column name of the AGR_USERS table assigned to check the field name). The Field value must have the value of the UNAME field value.

Follow steps 4, 5, and 6 to enter those values. They provide guidance on how to create a Function ID and Risk ID.

All input fields are prerequisites of step 3 to create a supplementary rule. Refer to steps 4, 5, 6, and 7 to create a SoD function.

Step 3. Create a Function ID and Risk ID for a physical SAP ERP connector. A business area is a category in which risk analysis results are displayed. An action and a transaction are the same. An action is an activity that is performed in a system to complete a task – for example, CO01. The system refers to a plug-in or ERP system such as SAP ERP or SAP CRM. Figure 9 shows how to create a new function.

To reach Figure 9 log on to the ABAP client for GRC. Execute transaction NWBC > cockpit nwbc. Click the NWBC hyperlink. Follow menu path Setup > Access Rule Maintenance > Function. Click the Create button. Figure B in the sidebar shows the Create button on the SOD Function view. Fill the Action tab as shown in Figure 9.

Figure 9

Create one function (SUP_FUN1)

There are two functions you have to create for a SoD risk: SUP_FUN1 and SUP_FUNC. In Figure 9 fill the required fields and click the Save button. A SoD risk has a unique Function ID and then a description, business process, and analysis scope. For example, Analysis Scope is a Single System. It means you are taking a single physical connector. An Action tab in a function can have any action or transaction.

SUP_FUN1 is the first function associated with actions CMOD (Enhancements) and CO01. A user must use transactions that can execute in the plug-in system. For example, if SAP_USER1 can create a production order, then CO01 is a transaction or action.

Step 4. Set the function’s permission in Active status. Figure 10 shows the first function’s Permission tab. The SUP_FUN1 function has some Permissions associated with the CO01 action.

Figure 10

Permissions in the Permission tab to create function SUP_FUN1

Permissions of the CO01 action and permissions name C_AFO_ATY (Authorization for Product order) are in active status for the SUP_FUN1 function. Active status means that only active status permission is considered when you are running SAP Access Control risk analysis. Inactive permissions are excluded in risk analysis. Generated rules should have all active permissions and field values. Figure 10 shows a Status column in the Permission tab. The Status column has a drop-down menu with two field values: Active and Inactive. Set the status as Active for it to be considered in SAP Access Control risk analysis.

Step 5. Provide authorizations or permissions in the plug-in system associated with the actions. You expand the authorization object and update the authorization object elements as needed. Permissions are defined in SAP Access Control permission level risk SUP_ROLE2, which is associated with action CO01 with permissions and activities to create a permission level risk. To get an overview of the permission level risk, refer to the sidebar “Tracking Risks with ARA.”

Log on to the ERP plug-in system and execute transaction PFCG. The Create Roles screen appears (not shown). Input the description of the new role and click the Save button. Click the Authorizations tab and then click Change Authorization Data.  This action displays the Change Role: Authorizations screen (Figure 11)in which you can manually select the input of the authorization object by clicking the maintained (green icons).

Figure 11

Authorization view of a role (SUP_ROLE2) in the SAP ERP system

For example, two roles, SUP_ROLE1 and SUP_ROLE2, are created. In Figure 11, SUP_ROLE2’s Activity 01 to create or generate is in active status (green).That means user SUP_USER2 has the authorization to execute the transaction with create or generate permission.

Regarding permission level risk analysis, you can generate permissions of one role or both. For example, permission for role SUP_ROLE2 has been generated in the plug-in system, but was not generated for role SUP_ROLE1. For more information about the authorization concept, click these links: Authorization and SAP Authorization Concept.  

Step 6. Create a second function and define an action to create a permission level SoD risk. Execute transaction NWBC and follow menu path Setup > Access Rule Maintenance > Function. The next screen contains the Create button. Click the Create button to go to Figure 12, which describes a second function, ID SUP_FUNC. It is associated with the actions MM01 and XD01 and permission BUKRS (company code). To save the second function, you need to create a function to create a SoD risk permission level risk. Figure 12 shows an Action assigned to a second function (the function ID is SUP_FUNC).

Figure 12

The SUP_FUNC fucntion Action tab

Step 7. Create the Permissions of a transaction defined under the Permission tab of a Function. Functions with actions and permissions come together to form risks. Click the Permission tab in Figure 12 to view information for the second function (Figure 13). The Function ID is SUP_FUNC, which has permissions associated with transaction code MM01 (Create Material). Function SUP_FUNC is associated with a permission that is defined in the ERP plug-in system. This step explains how to provide permission for an action in a function. To create a permission level risk, you need to create a function that has a permission. These Permission Group and Permission fields match with the authorizations of the plug-in system.

For example, function SUP_FUN is a grouping of actions (MM01and XD01) and a permission (BUKRS). BUKRS is an organizational value that is called Company Code.

Figure 13

Permission Group and Permission Field value of the second function (SUP_FUNC)

Figure 14 describes the organization levels of an action. An organization level is an organizational entity. A user is assigned to a role, and a role is assigned to transactions. Transactions are assigned to an authorization. An authorization is assigned to an authorization object (OrgLevels). For example, a user can execute transaction code MM01 with an authorization object in the ERP plug-in system. Figure 14 refers to the assigned permissions detail (Name, Fields, and Value from).

Figure 14

Authorization of PFCG role SUP_ROLE1 in the SAP ERP plug-in system

Refer to Figure 14 to see the user’s or role’s authorizations defined in the plug-in system.

Step 8. Create the Risk ID. For supplementary rules you only have to create the permission level SoD risk. Log on to the ABAP client for GRC. Execute transaction NWBC. Click cockpit nwbc and hyperlink NWBC. Follow menu path Setup > Access Rule Maintenance > Risk. After you click the Risk hyperlink, you see a Create button as shown in Figure 15. Click the Create button to go to Figure 16.

Figure 15

SoD risk view associated with the Create button

Figure 16

SUP_RISK is a SoD (permission level) risk to crate a supplementary rule

Now you need to fill all the input parameters to create a Risk ID. Click the Save button to save the risk. In Figure 14 you are going to create a SoD risk, the associated functions SUP_FUN1 and SUP_FUNC, and rule sets. A rule set defines categories or groupings of rules. As with business processes, they are used mainly as a filter when searching for risks or rules. For example, risk ID (SUP_RISK) is a SoD type risk at a medium risk level.

Step 9. Generate a rule. Rule generation is an SAP Access Control feature to generate a rule on the combination of actions and permissions. When you generate SoD action risks, Risk Analysis and Remediation creates a separate rule for each combination of actions that pose a risk.

To generate a rule, log on to the ABAP client for GRC and execute transaction NWBC > cockpit nwbc. Click the NWBC hyperlink and follow menu path Setup > Access Rule Maintenance > Risk. Click the Risk hyperlink. After you click the Risk hyperlink, the screen shown in Figure 17 appears. Select one of the risks shown in Figure 17 and click the Generate Rules button. Rules can be generated in foreground or background mode.

Figure 17

Generate a rule

In the next screen (Figure 18) you need to confirm the Risk ID. Click the Confirm button.

Figure 18

Rule generation view to confirm the Risk ID

That action takes you to Figure 19 in which you see links named View Action Rules and View Permission Rules. Figure 19 is a rule generation view that has action rules and permission rules. This is developed to generate rules for Permission, Critical Action, or Critical Permission levels. Click the View Permission Rules link to go to Figure 20.

Figure 19

Action and permission rules links

Figure 20 is a view of the permission rules. It shows the total number of action and permission functions and rule IDs in a rules generation report. Rules are generated from risks. If you want to delete or modify a rule, you need to modify or delete the risk. To modify or delete the rules, use edit mode.

Figure 20

Detailed information of generated rules

Step 10. Create a supplemental rule view. Go to the NWBC cockpit and follow menu path Setup > Exception Access Rules > Quick Links > Supplemental Rules (Figure 21). There is a view to create a new supplementary rule. The view has a Save button on the left corner to save data. It shows the parameters that are required to create a new supplementary rule. After entering values in the following fields, click the Save button:

• System: GI7CLNT600 (ERP plug-in system).
• Access Risk ID: SUP_RISK (it’s a permission-level SoD risk).
• Function ID: SUP_FUNC associated with transactions of the GI7CLNT600 system.
• Table Name: AGR_USERS is a data table name in the GI7CLNT600 plug-in system.
• Check Field Name: UNAME is a field/column name of table AGR_USER.
• Include Violations: No.
• Field NAME: AGR_NAME.
• Field Value: SUP_ROLE*.

Figure 21

Supplementary rule parameters

The following steps are required to create objects (user or role) in the plug-in system for creating a SoD risk in SAP Access Control:

Step 1. Create a user and roles in the SAP ERP system. You can define the user as an employee who has roles and authorizations to perform a task.

Table 1 shows the objects (user or role) created in the ERP plug-in system. For example, SUP_USER1 is a user name that is created after you execute transaction code SU01. (You create a user in the GI7CLNT600 system.)

Every user has some roles and responsibilities. SUP_USER1 is associated with two roles named SUP_ROLE1 and SUP_ROLE2. These two roles are created by executing transaction code PFCG. Actions F-01, MM01, XD01 are defined in SUP_ROLE 1. CMOD, CK68 (Release Costing Run), and CO01 are defined in SUP_ROLE2.

To run supplementary risk analysis, you must create a user in the ERP plug-in system. To create, delete, or update a user in the plug-in system, execute transaction code SU01 in the ABAP plug-in system. The View User Maintenance screen (reached via transaction code SU01) has icons to create (F8), change (Shift+F6), or delete (Shift+F2). F8, Shift+F6, and Shift+F2 are the short keys to open these icons. Execute transaction code SU01 and click the display icon. This action displays the screen shown in Figure 22 in which the user name is associated with the roles SUP_ROLE1 and SUP_ROLE2. Figure 22 shows the sample data of created users and associated roles in the plug-in system.

Figure 22

User role information

Figure 23 shows the transactions defined for a role. It shows the sample data of the role and actions. To reach Figure 23 log on to an ERP plug-in system. Execute transaction code PFCG. Two roles (SUP_ROLE1 and SUP_ROLE2) are assigned to user SUP_USER1. The roles have access to User SUP_USER1 and transaction codes (F-01, MM01, XD01, CMOD, CK68, and CO01). Figure 23 shows the transaction codes for SUP_ROLE1 and the actions to take in this screen to assign transactions in this role (SUP_ROLE1). A user can take any action that is assigned to a role, but I have created sample data using F-01, MM01, and XD01.

Figure 23

Details for SUP_ROLE1

Next, click the icon at the end of the Role field and select SUP_ROLE2. Press Enter. That takes you to Figure 24, which shows the approved transaction codes for SUP_ROLE2.

Figure 24

Details for SUP_ROLE2

Step 11. Name the tables and provide a detailed description of the supplementary rule table and field name. Enter a description of table AGR_USERS and the associated field name. This is mandatory input.

The GRC supplementary table name is GRACSUPPRULEHDR. GRACSUPPRULEHDR is not case sensitive. To open the supplementary rule table, execute transaction code SE11. In the screen that appears (Figure 25), enter the table name as GRACSUPPRULEHDR. The GRC database table is found in GRCFND_A in SAP Access Control 10.0 and 10.1.

Figure 25

Supplementary rule table information

A supplemental rule has a unique supplemental RuleID associated with a risk ID, database table, field name, and field value.

The GRAC supplementary table exists in the SAP Access Control system. The supplementary database table starting with the GRAC prefix exists in an SAP NetWeaver system in which a GRCFND_A software component is installed.

An SAP database table contains user or role information. For more information go to this link: AGR_USERS. Database table AGR_USERS is a table in the back end that has information about users and their roles. For example, the AGR_USERS table is a table name in the plug-in system.

Figure 26 shows the AGR_USERS table after you execute transaction code SE11. This is a database table with the created users’ name (SU01) list and roles name (PFCG) list corresponding to AGR_NAME and UNAME field or column name, respectively. The fields AGR_NAME and UNAME have all existing roles and users, respectively.

In a similar way, USR02 and VIRSA/ORUSERS are the database tables with the field or column name BNAME and VON, respectively.

The flowchart in Figure 1 shows the role names created in the ERP plug-in system (GI7CLNT600). SUP_ROLE1 and SUP_ROLE2 are created from transaction code PFCG. They are in the table AGR_USERS’s AGR’s_NAME field.

Figure 26

The AGR_USERS table's field name information (sample data of the plug-in system)

Figure 27 shows the user name SUP_USER1 that is created from transaction code SU01 and is in the table AGR_USERS’s UNAME field. This is sample data to check the field name to create a supplemental rule.

Figure 27

The AGR_USERS table's field name UNAM information

After you create a supplemental rule you need to do risk analysis. The risk analysis is known as supplementary risk analysis.

Supplementary Analysis in SAP Access Control Risk Analysis in 10.x

The purpose of a supplementary rule is to eliminate false positives based on authorizations or permissions and organizational level restrictions. This functionality was created to aid exception-based reporting for organizational rules and supplemental rules.

Only one supplementary rule is considered for each violation, whichever is the first satisfied. If there are two supplementary rules defined and one is to show the violation and other is to not show the violation, then there is no way to decide which one takes precedence.

Now log on to the ABAP client for GRC. Execute transaction code NWBC and follow menu path cockpit nwbc. Click the NWBC hyperlink. Choose the work center Access Management and follow menu path Access Risk Analysis > User Level. Click the User Level hyperlink. This action displays the SAP Access Control Risk Analysis: User Level screen (Figure 28).

Figure 28

Supplementary rule risk analysis

Following is sample data for a user:

System: GI7CLNT600 is associated with user SUP_USER1 at the permission level. For example, risk analysis for user SUP_USER1 is created in the plug-in system GI7CLNT600.

Risk analysis results: There is no risk analysis results because although you created a   supplementary rule, the option NO is selected for including a violation.

You can perform risk analysis to identify risks associated with a user, role, profile, or human resources (HR) object. ARA supports real-time compliance to detect risk. A user checks the assigned action to the role in the plug-in system and matches the action in generated permission rules. However, in a supplementary rule, there is an option to include that the violation=NO. Therefore, no violation shows in the risk analysis report for SUP_RISK.SUP_RISK assigned to a supplementary rule.

Figure 29 shows Supplementary Rule data. To go to Figure 29 follow menu path Setup > Exception Access Rules > Quick Links > Supplemental Rules. Click the Open button. Figure 29 shows that I changed the condition in the supplementary rule view to say Yes for a user-level risk analysis check. The associated role and action are matched with the generated rule for supplementary database table AGR_USERS. The field name UNAME AGR_NAME has the assigned FIELD_NAME values.

Figure 29

Condition changed to Yes

Figure 30 shows the supplementary risk analysis report on the basis of include violation Yes. You need to do a user-level risk analysis. To go to Figure 30 go to cockpit nwbc. Click the NWBC hyperlink. Choose the work center Access Management and follow menu path Access Risk Analysis > User Level. The supplementary risk analysis shows the number of violations on the basis of the supplementary rule.

Figure 30

User level risk analysis showing results because the supplemental rule has included the violation value = Yes

Step 12. Generate an organization rule in the front-end SAP Access Control application for an ERP plug-in system. Supplementary Organization Rule Analysis in SAP Access Control 10.0 and 10.1 eliminates false positives based on organizational-level restrictions. Take these steps to generate the organization rules.

Create Org Levels in the back-end connector for SUP_ROLE1 and SUP_ROLE2. (The plug-in system is also called the back-end connector.) To create an organizational rule in SAP Access Control 10.x, go to the NWBC cockpit. Go to the work center Setup and follow menu path Exception Access Rules > Quick Links > Organizational Rule. In the Organization rule screen, click the Create button. The SoD organization rule create view is displayed, as shown in Figure 31. SUP_ORG_SU is an organization rule ID, which is user defined.

The user enters the Risk ID that is relevant for this org rule and corresponding organizational levels. The organization rule is based on an organization level. Each organization has a business area and a company code. For example, a user has access to org level Company Code (BUKRS). BUKRS value DE99 has SoD conflicts (risks). Parent Orgrule ID is not a mandatory field. Fill these values in the Organization Rule view and click the Save button.

Figure 31

View to create organizational rule SUP_ORG_SU

You need to define the Organizational levels of a role in the back-end connector or SAP ERP plug-in system. Figure 32 shows the Organizational Levels value of role SUP_ROLE1. SUP_ROLE1 was created by transaction PFCG in the plug-in system.

To go to Figure 32, follow menu path transaction PFCG > Create Role. Click the Authorizations tab and then click Change Authorization Data. Figure 32 shows that there are a few organizational levels defined in the ERP plug-in system, including Company code, Business area, and Account type. For example, Role SUP_ROLE1 is assigned to a transaction (Material Master), Permission has Activity value 01, and the Org. Level BUKRS value is DE99. The Org. Level (BUKRS) company code has been assigned to transaction M_MATE_BUK.

Figure 32

Role SUP_ROLE1 authorization view in the plug-in system along with the organizational level

The parameters for the Organization rule creation screen are listed in Table 2. They show the user-defined Org Rule ID, Risk ID, Org Level, and Value. The Org rule helps with organization-level risk analysis for a user.

Step 13. Execute the org level risk analysis with a supplementary rule, including the violation as Yes. While running a regular risk analysis, the user would show up with a SoD conflict, as both conflicting transactions are assigned. To find out if the risk exists for the same company code, you can use the organizational rule. Therefore, create an organizational rule that filters the company code and apply this org rule to the risk analysis.

To reach Figure 33 go to the NWBC cockpit and the work center Setup. Follow menu path Exception Access Rules > Quick Links > Organizational Rule. Figure 33 shows the list of org rules.

Figure 33

Organizational rule list data view

Go to the work center Access Management and follow menu path Access Risk Analysis > User Level. Click the User level hyperlink. The next screen is the risk analysis with the Consider Org Rule check box (Figure 34). Check the Consider Org Rule check box. The figure shows the view of OrgLevel user level risk analysis.

Figure 34

Risk Analysis view with the Consider Org Rule check box

Click the Run in Foreground button to go to Figure 35, which shows the Org Level risk analysis for SUP_USER1 with org rule SUP_ORG_RU. For example, user SUP_USER1 has two assigned roles (SUP_ROLE1 and SUP_ROLE2).

Role 1 (SUP_ROLE1) has actions MM01 with authorization object M_MATE_BUK and the Activity value 01. It has an org level-defined company code (BUKRS) value (DE99) and a second action XD01 (Create Customer).

Role 2 (SUP_ROLE2) has actions CO01 and CK68. A risk is defined with these transactions. If you execute User Level Risk Analysis for a user who has authorization, the system shows the violation at the permission level. Figure 35 shows the Org level SAP Access Control risk analysis report.

Figure 35

Organizational level risk analysis result report

When you create a supplementary rule, there is an input field named Include Violation. It has two values as a drop-down options: YES and NO. The table shows the results on the basis of the selected drop-down value.

The expected behavior of a user-level org rule analysis with a supplementary rule regarding SoD violations is to either to include or not include violations in an access risk analysis report.

Table 3 shows the conditional output of org level risk analysis defined at the organization rule level with a supplementary rule.

Akansha Gupta

Akansha Gupta, senior developer, SAP Labs India Pvt. Ltd., has eight years of experience in SAP Labs India Pvt Ltd. and more than nine years of experience in the IT industry. Akansha is currently working with the Installed Base Maintenance Support (IMS) organization, SAP Labs, India, for SAP Access Control 5.3, 10.0, and 10.1. Akansha has vast experience in GRC and worked on multiple skills and technologies including BRF+, SAP UI5, HANA, JavaScript, Java, web services, OData services, ABAP WebDynpro, ABAP OO, SAP ABAP dictionary, and function modules for a broad range of SAP modules and the SAP Access Control ARA, ARQ, BRM components.

You may contact the author at akansha.gupta@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.