The following examples show how rules can be created with the help of the Rule Editor and the effects of each option.
Employees from department A may not belong to department B at the same time.
Figure 5: Rule Condition for Example 1
Employees that belong to the department sales or the department purchasing, are not permitted to access the Active Directory group "Development". This rule is only checked for enabled employees.
Figure 6: Rule Condition for Example 2
All permitted entitlements are assigned to employees over system roles. One employee can have a maximum of two system roles. If an employee has more than one identity, the rule is also violated if the entitlements of all subidentities together result in a rule violation.
There are three system roles: Pool for finance, Pool for purchasing, Pool for sales
Jenny Basset has two subidentities. The main identity and both subidentities are respectively assigned to a system role.
Jenny Basset (HI): Pool for finance
Jenny Basset (SI1): Pool for purchasing
Jenny Basset (SI2): Pool for sales
Because Jenny Basset's main identity includes all three system roles due to her subidentities, the main identity violates this (and only this) rule.
Rule checking finds the same result if the rule is formulated as follows:
|Configuration parameter||Meaning if Set|
|QER\ComplianceCheck\SimpleMode\NonSimpleAllowed||Rules can be created in advanced mode|
There are two ways of defining rule conditions, the simple definition and advanced mode. The simple definition is used as default to create rule conditions with the Rule Editor. For more information, see Basics for Using the Rule Editor.
In advanced mode, employee's properties are defined in the rule condition that lead to a rule violation. The assignments are determined directly by the respective base tables, which contain the selected objects (for example, PersonHasSAPGRoup or Person).
To use advanced mode
On the rule's master data form you will also fund the options Rule for cyclical testing and risk analysis in IT Shop and Rule only for cyclical testing.
The design of the rule condition is changed.
|NOTE: You cannot return to the simple definition once a rule condition has been entered in advanced mode!|
|NOTE: Rules in advanced mode are not taken into account by rule checks within IT Shop request approval processes. No IT Shop properties can be defined for these rules. The IT Shop properties tab does not appear on the master data form for this rule.|
Figure 7: Advanced Mode Condition
Rule conditions in advanced mode are based on the base object "Employees" (Table Person). The completed database query is put together internally:
Select Firstname, Lastname from Person where <Rule condition>order by 1,2
First you need to specify whether one or all of the following conditions have to be met in advanced mode. Specify the condition type in the first drop-down menu in the condition.
|Property||Employee object properties. The drop-down menu with permitted properties is already restricted to the most important employee properties.|
|For the account with the target system type||Employee’s user account. Valid user account properties depend on which target system is selected.|
|For entitlements with the target system type||Employee target system group. Valid group properties depend on which target system is selected.|
|SQL Query||Free choice of SQL query (WHERE clause). Click if you want to use the WHERE clause wizard.|
You have the option to link several conditions together. Only "and" is supported here as link operation.
All other control elements you need for formulating a condition, are operators and properties. You can only select one entry from the drop-down menu. You can select more entries from extended drop-down menus, where the properties are displayed hierarchically and then added to the condition using an "or" operator. You may enter text directly into input fields. Pop-up menus and input fields are shown and hidden dynamically.
|Configuration parameter||Meaning if Set|
|QER\ComplianceCheck\PlainSQL||SQL text is only permitted for rules in advanced mode.|
You can formulate rule conditions directly in advanced mode as an SQL query.
To formulate a rule condition directly as an SQL query
|NOTE: Rule conditions can only be formulated through an SQL query if the configuration parameter "QER\ComplianceCheck\SimpleMode" is not set and the configuration parameter "QER\ComplianceCheck\PlainSQL" is set.|
Figure 8: Direct SQL Query Input
NOTE: All the information about a rule condition and rule violations is irrevocably deleted when the rule is deleted! The data cannot be retrieved at a later date.
Therefore, we advise you to write a report about the rule and its current violations before you delete it, if you want to retain the information (for example, audit security).
You can delete a rule if there are no rule violations attached to it.
To delete a rule
Any existing rule violations are removed by the DBQueue Processor.
The rule, the associated rule violation object and the working copy are all deleted.