Role Methodology Overview
The role creation process consists of predefined methodology actions and the methodology steps associated with those actions. The steps then create a methodology that guides you as a role designer through the process of defining, risk analyzing, approving, generating, and testing a role during role creation or maintenance. Based on the steps, you can determine the phase of the role creation or maintenance process.
In the preceding screenshot, you can see how to define role methodology in the transaction SPRO under Governance, Risk and Compliance → Access Control → Role Management → Define Methodology Processes and Steps.
The methodology allows a process flow enforcing for the role creation and maintenance operation. SAP Access Control also provides a framework of BRFplus to apply rules to dynamically select a methodology from the available list of methodologies, based on role attributes. Customers can document and enforce a well-defined role creation process according to the organization's policies.
Business Example
An organization wants to enforce the Approval phase after the Derive Role phase for all roles. But for roles that are classified as Sensitive, the organization's policy states that these roles must be approved twice: once following the Risk Analysis phase and again after the Derive Role phase.
Using the configuration option for defining the role methodology and steps, rules can be created according to the requirements.
Organization Needs:
Each organization may have different role creation processes, which are often dictated by the intent of the role. A risk-sensitive role that provides access to financial information may require an approval. A role that allows users to print a document may not need an approval at all.
BRFplus Rule Configuration
SAP Access Control offers a Business Rule Framework plus functionality as a business rules management system, which provides a comprehensive application programming interface and user interface for defining business rules. It is a flexible rule engine that evaluates the attributes of a role. You can configure the use of condition groups that are defined from a set of role attributes and map different role methodologies depending on the role criteria. This provides you with the flexibility to have different steps depending on role information. For example, the approval phase may be required for roles of business processes Finance and HR but not for others.
Condition Groups:
Different condition groups can be defined for different values of role attributes, such as:
- Business process.
- Subprocess.
- Functional area.
- Role type.
- Role name.
- etc.
The system applies a condition group to a role creation process to override the default role creation process when the criteria from the condition group are met.
Note
Multiple condition groups can be applied in one role creation process, but multiple processes can’t be associated to one condition group.Before the BRFplus functionality was available, developers had to maintain the attribute values in a customized table and had to fetch the corresponding value maintained from the customized table. The business had no visibility into how the systems take decisions and changes were difficult. With BRFplus, roles can be mapped with rules centrally and in an intuitive way. Rules can also be reused in different applications. The starting point of the BRF+ framework is the transaction code BRF+. A BRF+ rule is required to use Role Methodology functionality. The BRFplus rule determines the condition group based on role attributes’ values. You as an administrator specify attributes’ values and map condition group ID to each value in BRFplus rule. Then in SPRO configuration you map each condition group ID to a particular role methodology.
The process of configuring a customized role methodology with BRF+ consists of four main steps.
- Firstly, you need to create a BRFplus application with a decision table.
- As a second step, you define the mapping of role attributes' values to a particular condition group (condition group ID) in the decision table.
- Then, you need to create role methodology processes with steps. You can create as many methodology processes as necessary. For example, you might want to have one methodology for Finance role requests and another for HR role requests.
- Finally, you need to associate each condition group ID with a role methodology to determine which methodology is triggered for which role attributes’ values.