• Modeling authorization, including role building and authorization metadata
• Run time execution of authorization checks

Modeling Authorization

You need to use SAP-delivered authorization objects to build functional roles. Specifically for SAP Process Control application and role modeling, you use these authorization objects: GRFN_API, GRFN_USER, and GRFN_REP.

Roles are generated via transaction code PFCG and are a superset of authorization objects. I discuss role building and explain in detail ENTITY, SUBENTITY, ACTIVITY, and DATAPART. There is a separate guide in SCN about different functional roles delivered with SAP Process Control 10.0. Users also have the flexibility to create Z-roles based on their independent requirements using authority objects.

First, I cover how to build SAP Process Control roles and then explain how to assign these roles to SAP Process Control entities (see the “Different Authorization Modes” section).

The authorization objects GRFN_API, GRFN_USER, and GRFN_USER are pre-delivered by SAP and can be accessed via transaction code SU21.This way, you have an overview of standard delivered objects upon which business roles are modeled. You need to add these authority/authorization objects and customize your business roles.

You can either use the SAP-delivered roles with these authority/authorization objects or copy these standard roles into the customer namespace. To review the authority objects, execute transaction code SU21 and expand the GRC folder (Figure 1). In Figure 1, note that three authority objects (GRFN_USER, GRFN_REP, and GRFN_API) are used to build standard and customer-specific roles in SAP Process Control.

Figure 1

Authority objects for building roles

Role Building

The standard SAP roles and customer roles are built on authority objects. However, you need to have a clear understanding of sub-objects such as ENTITY, SUBENTITY, DATAPART, and ACTVITY for different authority objects.                                                                                                       

Authorization for Access via GRC APIs

The application programming interface (API) API CL_GRFN_AUTH_ENGINE is a dedicated class of API for run time authorization checks based on roles configured for the user. The system automatically executes these checks, and specific work centers are visible to the users when they log in to the system. (I discuss this topic in more detail in the “Run Time Execution of Authorization Checks” section.) As part of implementing SAP Process Control, you need to understand only the different sub-objects such as ENTITY, SUBENTITY, ACTIVITY, and DATAPART for a particular authority object.

The role for the authority/authorization object GRFN_API consists of the following sub-objects:

• Entity
• Sub-entity
• Activity
• Data part

To maintain the Entity sub-object, execute transaction code SU21 and expand the GRC folder (Figure 2). Double-click the authority object GRFN_API.

Figure 2

An overview of GRC authorization objects

In the next screen, populate the fields as shown in Figure 3. Note that authority object GRFN_API contains the four fields listed in the Authorization Field column of Figure 3. Entity is the type of object and key value from the table GRFNOBJTYPE. For example, an organization is one entity, and control is another. Each entity is accessed via a dedicated entity API class.

Figure 3

Authority object GRFN_API contains four fields

Execute transaction code SE16 and display table GRFNOBJTYPE (Figure 4). This table is not specific to SAP Process Control only. For example, in the overview of different GRC entities shown in Figure 4, organization is one entity derived from table GRFNOBJTYPE.

Figure 4

Table GRFNOBJTYPE can be referenced for the entity

Some entities require more granularity, and this can be specified via the sub-entity. Test Log G_TL, for example, is an entity and there are sub-entities such as CO, MO, MTOU and TE under G_TL.

To build roles or use standard roles, execute transaction code PFCG. After you select the entity as G_TL (test log), choose sub-entities for the test log. Figure 5 shows different sub-entities for the G_TL entity.

Figure 5

Sub-entities for the G_TL entity

To maintain the Activity sub-object, follow the standard SAP authorization activities. The system supports mainly 02 (change) and 03 (display).The activity 01 (create) and 06 (delete) can be included per entity. This means that CREATE and DELETE activities are automatically granted with CHANGE and DISPLAY activities and that you need to add them explicitly for the entity.

To navigate from the GRC authority object GRFN_API, execute transaction code SU21. This action opens the screen shown in Figure 6. Double-click the Permitted Activities button to see an overview of permitted activities in the Define Values screen.      

Figure 6

Activity follows the SAP standard authorization

For some entities for activity 02 (change), the authorization concept needs to support the partial update authorization. Therefore, the user is allowed to change only some fields of the update structures, but not others. To explain this better, I include an example named “Decentralization: Organization and Sub-process Maintenance” in the “Application Scenarios” section.

Examples of data parts are DATA and ROLES_PC for the entity organization. Table GRFNDATAPART has the information about different data parts related to one entity. To access this table, execute transaction code SE16 and display the table GRFNDATAPART (Figure 7).

Figure 7

Table GRFNDATAPART can be referenced for entity Org Unit and data part DATA

This table shows different data parts that can be maintained for a particular entity. I have highlighted the organization unit (ORGUNIT) entity as an example. Metadata about authorization specifies some rules about how to deal with authorizations for particular entities. There are two main metadata configurations: authorization hierarchy and unique flag.

Authorization Hierarchy

The entities must be organized to the hierarchy so that you can expand the authorization upward and downward. To maintain an authorization hierarchy, execute transaction code SPRO and follow menu path Governance, Risk and Compliance > General Settings > Authorizations > Maintain Authorization Customizing. This action opens the screen shown in Figure 8. Click the execute icon beside Maintain Authorization Customizing.

Figure 8

IMG for authorization metadata

For my example I specify the metadata about Role Inheritance for Organizations (Figure 9). Note that I selected the following check boxes:

• Display inherited role assignments
• Extended role setup consistency check
• Role Inheritance for Organizations

Click the save icon to save your entries.

Figure 9

Role Inheritance for Organization activated

Unique Flag

Some entity/activity combinations can be set as unique so that the authorization can be granted only to a single person for the particular object — for example, Relevant Roles for GRC Authorization in the SPRO configuration. To set a unique flag for a role, execute transaction code SPRO and follow menu path Governance, Risk and Compliance > General Settings > Authorizations > Maintain Entity Role Assignment. Click the execute icon beside Maintain Entity Role Assignment (Figure 10).

Figure 10

Execute Maintain Entity Role Assignment

This action opens the screen shown in Figure 11. Note that in Figure 11, I selected the check box for the Cross Regulation Control Owner role (SAP_GRC_SPC_CRS_CTL_OWNER) in the Unique column. This configuration means that no other owner can be assigned as the cross-regulation control owner for the related control.

Figure 11

Unique flag checked for the functional role

Authorization Object for GRC Users

The special mechanism to bypass the authorization is available for power users (they have permission granted for all the authorization checks) and display users (they have permission granted for all the display checks). Authorization is controlled by the authority object GRFN_USER for business users without power or display rights. To access the authority object GRFN_USER, execute transaction code SU21 and go to the GRC folder. Expand this folder and double-click the authority object GRFN_USER (Figure 12).

Figure 12

Access authority object GRFN_USER

In the screen shown in Figure 13, double-click the authority object GRFN_USER in the Object field and click the Permitted Activities button. The Display Values screen shows an overview of the permitted activities for this authority object.

Figure 13

Permitted activities for authority object GRFN_USER

The authorization field ACTVT has the following permitted activities:

• 02: Power user authorization
• 03: Display user authorization
• 10: Enables ad-hoc tasks, such as Record an Incident or Propose a Risk.
• 16: Execute: This is used to enable the business user for the built-in GRC authorization concept. For example, users could only execute a task if they have activity 16 authorization.
• 58: Own delegation.
• 59: Central delegation.

Authorization for GRC Reporting

Process Control reports have an authorization check in the menu, which means that only authorized business users can execute the particular report. The menu for a particular report depends on the authorization check for the business users on PC entities such as organization, sub-process, or control.

See the view cluster GRFNVC_ITEMAUTH via transaction code SM34 where Item Authorization Class drives the menu for a particular report. Different reports have unique authorization entities and authorized objects configured depending on their traversal path.

This setting is just for your reference only and is not customizable.

SAP delivers this configuration, and it is correct in all scenarios. Execute transaction code SM34 and open the view cluster GRFNVC_ITEMAUTH (Figure 14). View cluster GRFNVC_ITEMAUTH has an item authorization API class for each report menu.

Figure 14

View cluster GRFNVC_ITEMAUTH

The authority object GRFN_REP is used for the business user to print and analyze different reports. Otherwise, there would be no data in the report, as there would be no authority to print any objects.

As part of building the business role, you need to ensure that the authority object GRFN_REP is added with the required activities to the role. To access the GRFN_REP authority object, execute transaction code SU21 and follow menu path GRC > GRFN_REP (Figure 15). Double-click the GRFN_REP authority object.

Figure 15

Access the GRFN_REP authority object

In the next screen, double-click the authority object GRFN_REP in the Object field and click the Permitted activities button (Figure 16). The Define Values screen shows an overview of the list of permitted activities based on which you need to model your role.

Figure 16

Permitted activities for the authority object GRFN_REP

Run Time Execution of Authorization Checks

After the authorizations are properly modeled and users are assigned, the run time code can actually perform the authorization check. This is implemented by the API class CL_GRFN_AUTH_ENGINE. To access this engine, execute transaction code SE24. This action opens the screen shown in Figure 17.

Figure 17

Authorization engine API for run time execution of authorization checks

Click the Methods tab to view run time checks implemented in API class CL_GRFN_AUTH_ENGINE. The SAP system delivers the run time checks in API. However, for sake of the completeness of the authorization model, I recommend that you know the class that handles the authorization framework.

Different Authorization Modes

SAP Process Control has pre-delivered functional roles as well as the flexibility to build custom roles. The authorization to execute master data, perform assessments, and schedule automatic jobs depends on the specific authorization of the particular business user. There are three possible modes:

• Entity-level authorization
• Entity-level with second level authorization check
• Ticket-based authorization

Entity-level authorization is derived by assigning the functional role to the business user directly in the SAP Process Control on the end user interface (UI). You need to maintain an Entity Role Assignment through SPRO first. To complete this activity, execute transaction code SPRO and follow menu path Governance, Risk and Compliance > General Settings > Authorizations > Maintain Entity Role Assignment (Figure 18). Click the execute icon beside Maintain Entity Role Assignment.

Figure 18

Define functional roles related to SAP Process Control entitities

In the screen shown in Figure 19, you define the functional roles that can be assigned to an entity. In my example, I configure the cross-regulation control owner role (SAP_GRC_SPC_CRS_CTL_OWNER) for the CONTROL entity. Now you can define this role in the front-end user interface.

Figure 19

Functional role maintained for a control so that business users can be assigned the role in the front end

A business role needs to be assigned to users for all SAP Process Control application entities, such as organization, sub-process, or control, via the front-end interface only. To do this, navigate to Portal > Access Management > GRC Role Assignments > Business Processes. Click the Business Processes link as shown in Figure 20.

Figure 20

Open Business Processes to assign a role at the Control level

In the next screen (Figure 21) select the Control check box for which a role needs to be assigned and click the Next button.   

Figure 21

Select the role level as Control to assign the roles at the control level

The Control owner is displayed in the screen shown in Figure 22.This is possible because I defined the entity role assignment as shown in Figure 19 and I assigned business user SAINIAM for the cross regulation role.

Figure 22

Select a specific control and you can see the highlighted role cross regulation

Second-Level Authorization Check

Through customizing via transaction code SPRO, you can activate a second-level authorization check. Follow menu path Governance, Risk and Compliance > General Settings > Authorizations > Maintain Authorization Customizing.This path takes you to the Authorization Customizing Maintenance screen (Figure 23) in which you can activate the second-level authorization by selecting the check box under the Active column in the row for Second-Level Authorizations and clicking the save icon.

Figure 23

Enable second-level authorization

To enable extra security, the business role can be defined at the user level via transaction code SU01 first, and then only the corresponding role can be assigned to a user for SAP Process Control entities.

This means the individual roles must be created and maintained with transaction code PFCG. Users who are assigned to roles via user-role assignment must first have the corresponding PFCG-modeled role and the functional roles SAP_GRC_FN_BASE and SAP_GRC_FN_BUSINESS_USER assigned to their user profile if second-level authorizations are active.

I explain this via an example and also cover the regulation role assignment. There are multiple compliances or regulations that controls inside an organization need to follow. For example, a control is relevant for Sarbanes-Oxley regulation. In this example, I want to assign the regulation-specific role cross-regulation Sarbanes-Oxley control owner to the business user AMS_S_CTLOWN with second-level authorization activated in my environment.

Therefore, I need to configure the following roles in transaction code SU01 as shown in Figure 24:

• SAP_GRC_FN_BASE
• SAP_GRC_FN_BUSINESS_USER
• SAP_GRC_SPC_SOX_CTL_OWNER

Figure 24

Assign functional roles

My use case is that I want to assign the user AMS_S_CTLOWN the standard role SAP_GRC_SPC_SOX_CTL_OWNER and second-level authorization is activated in the system. Execute transaction code SU01. In the screen that appears (Figure 24) select AMS_S_CTLOWN in the User field and click the Roles tab.

Two roles (SAP_GRC_FN_BASE and SAP_GRC_FN_BUSINESS_USER) must be assigned for users to access the SAP Process Control application in SU01 transaction code. Because second-level authorization is also activated, I need to assign the role SAP_GRC_SPC_SOX_CTL_OWNER in the same transaction code SU01. Only then, can I assign my user to role SAP_GRC_SPC_SOX_CTL_OWNER in the front end.

You execute SAP_GRC_SPC_SOX_CTL_OWNER at the CONTROL entity in IMG via transaction code SPRO. Because the role is regulation specific, the IMG for regulation level role assignment is a bit different. Follow menu path Governance, Risk and Compliance > Process Control > Authorizations > Maintain Regulation Role Assignment. This path takes you to the screen shown in Figure 25. Click the execute icon beside Maintain Regulation Role Assignment.

Figure 25

Entity role assignment required to be maintained for PFCG roles in order to be assigned at the front end

This action opens the screen shown in Figure 26 in which I assigned the role SAP_GRC_SPC_SOX_CTL_OWNER for the entity Control.

Figure 26

Cross-regulation functional role maintained via the IMG

Now, I can assign user AMS_S_CTLOWN to the role SAP_GRC_SPC_SOX_CTL_OWNER in the front end with second-level authorization enabled.

Ticket-Based Authorization

Some users need to have access granted for just a short period of time to perform activities related to the work items in their inbox. This should be implemented with ticket-based authorization, which can allow users to bypass the authorization concept driven by roles.

The objects in the work item itself are granted the update authorization, while the objects around are granted display authorizations. For example, there is a control inside SUB-PROCESS, so I have display authorization on SUB-PROCESS and edit authorization on CONTROL.

Ticket-based authorization is used to avoid deadlocks. Business users are granted only DISPLAY authorization per role assignment, but receive an assessment task for the control. For the business users to be able to execute the assessment task, they are automatically granted CHANGE on the CONTROL as well, so that they can complete the workflow task.

Ticket-based authorization is delivered by the SAP system and implemented via the CL_GRFN_AUTH_ENGINE API. To implement the CL_GRFN_AUTH_ENGINE API, execute transaction code SE24. In the screen that appears (Figure 27) display the class CL_GRFN_AUTH_ENGINE.

Figure 27

Ticket-based authorization injected and revoked in API CL_GRFN_AUTH_ENGINE

Central Delegation

There can be scenarios in which one business user is on leave and cannot process the task. Therefore, SAP Process Control provides flexibility to create delegation and work on behalf of some other business user inside the application. The delegation to other business users is maintained in the front end via menu path Access Management > Central Delegation. Navigate to the portal, click the Access Management tab, and click the Central Delegation link (Figure 28).

Figure 28

Delegation maintained to work on behalf of another user

In the screen that opens after you click the Central Delegation link, enter a user name and full name for the delegate as shown in Figure 29. Now user MISHRASE can work on behalf of user SAINIAM.

Figure 29

Delegate created to enable ticket-based authorization: delegate defined for user SAINIAM

Application Scenarios

In the last section, I list scenarios to set up authority objects and tailor business requirements effectively based on my experience in implementing and supporting SAP Process Control.

Decentralization: Organization and Sub-process Maintenance [Heading 3]

Because of specific security requirements, a business wants to separate organization maintenance from the ability to assign sub-processes to the organization. This is possible by configuring the following sub-object combination:

• ENTITY = ORGUNIT
• SUBENTITY = * , as sub-entity is not relevant for ORGUNIT
• ACTIVITY = CREATE or CHANGE, GENERATE
• DATAPART = ROLES, ROLES_PC,SUBPROCESS

To configure this sub-object, execute transaction code PFCG and include an authorization object GRFN_API with the combination as shown in Figure 30.

Figure 30

DATAPART DATA for entity OrgUnit is not maintained, but it is still possible to do the role assignment

Refer to SAP Note 1918551 for details about the decentralized model.

With this implementation, the business is not able to edit the general attributes of the organization, but can assign sub-processes or roles at the organization level. To access the general attributes for an Organization, follow menu path Master Data > Organization. In the screen that appears (Figure 31), open the relevant Organization (e.g., dummy_test_datasheet). In the pop-up screen that appears, note that the Save button is enabled for the organization.

Figure 31

User not allowed to change attributes of fields inside the General tab for the organization

Power/Display Enumeration

The special mechanism to bypass the authorization is available for power users (granted yes to all the authorization checks) and display users (granted yes for all the display checks). Although these users are bypassing the standard authorization, they still need to be treated as standard users under My Objects. A power or display user is allowed to do every transaction inside the SAP Process Control system.

Suppose this user is assigned several controls. Although he is a power user, he is only able to view the controls assigned to him. Log on to the SAP Process Control system and navigate via path My Home > My Objects > My Processes as shown in Figure 32.

Figure 32

Access to My Objects for a power user

Enumeration means that user Amit Saini, despite being a power user, has access to only those objects for which he is assigned as owner via role assignment in the front-end UI. All objects are not visible to a power user as well. Under menu path My Home > My Objects > My Processes, as an example, user Amit Saini is a standard user.

After you double-click My Processes, you are redirected to the screen shown in Figure 33. The power user can access all Work Centers in the SAP Process Control application, but he can only work on specific objects assigned to him via Entity Level Authorization.

Figure 33

The My Processes screen

The power user can see only the objects for which he is assigned a role, such as a standard business user. Enumeration means that user Amit Saini, despite being a power user, has access to only those objects for which he is assigned as owner. All objects are not visible, even to a power user.

Role Inheritance for Organization Authorization

In this example, one functional role, SAP_GRC_SPC_CRS_ICMAN, has the authorization to assign roles on the Organization, Process, and Control levels. To complete this task, execute transaction code PFCG. In the screen that appears (Figure 34), display the standard role SAP_GRC_SPC_CRS_ICMAN.

Figure 34

Business user has access to parent organization

To activate role inheritance for an organization, execute transaction code SPRO and follow menu path Governance, Risk and Compliance > General Settings > Authorizations > Maintain Authorization Customizing. This action opens the screen shown in Figure 35. Note that role inheritance for the child organization is activated.

Figure 35

Role inheritance for organization is activated

You need to select the check boxes for Display inherited role assignments, Extended role setup consistency check, and Role Inheritance for Organizations. Now suppose the business has the organization hierarchy as follows: Corporate Organization, Child Organization 1, and Child Organization 2. With role inheritance for the organization activated and the functional role configured for the corporate organization, the business user has change authorization on the two child organizations as well.

Reporting

The authority object GRFN_REP with ACTVT POST and ANALYZE determines the object being retrieved while fetching data from the back end. Otherwise, you see an error message saying “There are no data matching entered selection criteria,” despite the user being a power or display user. This happens while executing any report such as master data, assessment, or signoff with the business user.

Central delegation is possible with authority object GRFN_USER and ACTVT - '59'.

Schedule Automatic Control Jobs

Many function roles are delivered by SAP as standard — for example, Continuous Monitoring (CM) Job Specialist SAP_GRC_SPC_CRS_CM_JOB_SPEC. This contains authorization to schedule automatic control jobs via a scheduler. The authorization is derived from the authority object contained in the functional role. Roles such as CM Data Source Specialist, CM Business Rule Specialist, and CM Job Specialist can also be assigned to one user since the three roles contain the authority to maintain CM master data.

Amit Saini

Amit Saini is a specialist developer in SAP Labs India Pvt. Ltd. Currently, he is working with the IMS Organization (installed base maintenance support) for SAP Process Control 3.0, 10.0, and 10.1.; SAP Access Control 10.0; and SAP Risk Management 3.0. He has vast experience and worked on multiple technologies, including JavaScript, SAP UI5, HANA, ABAP WebDynpro, Workflow, BusinessObjects, Floor Plan Manager with ABAP WD, ABAP OO, Adobe Interactive forms, Adobe Flex Integration with ABAPWD, SAP ABAP Dictionary, function modules for a broad range of SAP modules, and SAP HR Organizational Management (Infotype, Time Constraint, Object Type, Subtype, Evaluation Path).

You may contact the author at amit.saini@sap.com.

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