What is the GRC 10.0 authorization concept and where can we use This authorization concept in the applications "Risk Management" and "Process Control" ?
There are various authorizations which any GRC user needs to have in order to be able to use the application. These are mainly technical authorizations need to be able to work with frameworks developed in NetWeaver and used by GRC.
Technically required SAP authorizations
All these technical authorizations are collected in the role SAP_GRC_FN_BASE. It is recommended to either use this role directly or copy it's contained authorization to a role which is then assigned to all GRC users (in transaction SU01 or PFCG).PFCG based foundation
The foundation for the ELA concept is a standard SAP authorization controlled by the authorization object GRFN_USER. With that object users can
you can marked as power users (ACTVT 02). This overrules all entity level authorization granted via GRFN_API (details below) and leads to the situation that this user is allowed to do "everything" within the application.
you can marked as display users (ACTVT 03). This overrules all entity level authorization granting display authorization via GRFN_API and leads to the situation that this user is allowed to display any object/information within the application.
you can marked as business users (ACTVT 16). This doesn't add any authorization to the user but indicates that further entity level authorization will be granted via business user roles defined by usage of the authorization object GRFN_API. The definition and usage of such business user roles is described in the next section.
Authorizations defined via GRFN_USER are granted via standard PFCG assignment of the corresponding role to the user.
Entity level authorization
Entity level authorization is defined by using the authorization object GRFN_API within role definitions. However, these application roles are not assigned to users within transaction PFCG or SU01 but directly in the GRC application on the end user UI. This is the main difference to the standard SAP authorization concept.
So how do these application roles work?
First of all the roles are setup in Role Maintenance (transaction PFCG) The authorization is granted through the authorization object GRFN_API. This authorization object contains the following fields:
GRC_ENTITY - The GRC entity (or object type) to which the authorization entry corresponds.
GRC_SUBTYP - Very few GRC entities can be further devided into subtypes. In that case the authorization can be split between the subtypes via this field.
ACTVT - Defines what can be done with the object: 01 Create, 02 Change, 03 Display, 06 Delete
GRC_DATAPT - For the activity 02 Change some entities allow further distinction for the kind of change that is supposed to be done on the object. This means a user might be allowed to change attributes A, B and C of some object but not attributes D and E. This would then be defined by so called dataparts.
The available dataparts per entity can be found on the table GRFNDATAPART.
What each datapart means should be described in the corresponding section application help. The leading datapart usually covering the main attributes is always called DATA.
The next step is to define on which entities the roles can be assigned. This is done in the customizing activity
- Governance, Risk and Compliance
- General Settings
- Authorizations
- Maintain Entity Role Assignment
Please note that this makes only sense for objects which do generally allow role assignments. These are
- Organizational Units (HR)
- Activities (HR)
- Risks (HR)
- Processes (HR)
- Subprocesses (HR)
- Controls (HR)
- Policies (non-HR)
Once this is defined the roles will show up on the corresponding object UIs (for example on the organizational unit maintenance screen) and users can be assigned on that level.
Here all users having the business user role assigned (GRFN_USER, ACTVT 16) are offered to be assigned to the various roles. This assignment basically replaces the assignment that is usually done in transaction PFCG or SU01. You can check the role assignments in the database on the tables HRP1852 (HR based objects) and GRFNROLEASSNMT (non-HR based objects). Once the assignments of the users to roles on object level have been done the system will perform authorization checks following a special logic (details below) by taking these assignments into account.
Please note that the role assignment is done time dependent and the authorization check is always performend for current date.
Traversal logic at runtime
The desired authorization logic is that every authorization defined within an application role (via GRFN_API) spans over all objects within the hierarchy subbranch under the object on which the user has the role assigned. The typical example for that is authorization coming with a role which is assigned to a user on a certain organizational unit. This authorization would be valid for all objects belonging to that organizational unit.
At runtime this logic is achieved by a special authorization check mechanism (not the standard AUTHORITY-CHECK command against SAP authorization) which starts from the object for which the authorization is requested and traverses the hierarchy upwards trying to find a suitable role assigned to the current user to allow the requested action.Further information
There is also a section in the application help describing the authorization mechanism. This section you can find under
- SAP Risk Management
- Key Concepts
- Levels of Authorization