Creating segregation of duties rules
To create a segregation of duties rule:
Navigate to the for a new rule. page
Type a unique ID and Description .
Determine whether the rule is Enabled.
Select Exceptions not allowed if you do not want users or reviewers to be able to request exceptions to the rule.
If you selected Exceptions not allowed, and you want to allow exceptions under certain circumstances, type the name of the plugin Program to enable exception.
A sample plugin,
plugin-sod-exception.psl
, is included in the <instance>\samples\. See Plugin to enable exception for more information about writing an exceptions plugin.Type the minimum Number of entitlements a user must have to violate a rule.
This means that if a user has at least this many of the rule’s configured resources, then they are in violation of the rule.
If set to 1, then all of the users for each of the rule’s resource members are in violation of the rule.
If set to 2, then users who are a part of two of the configured resource members are in violation.
If you want to vary the time that an exception will be allowed, type the Default number of days before expiry.
The default expiry is 60 days, as determined by EXPIRY FOR EXCEPTIONS TO SOD RULES (Manage the system > Policies > Options). Requesters can change this value when requesting an exception. After this time, a user granted an exception will be in violation again.
Click Add.
Next:
Plugin to enable exception
A segregation of duties (SoD) rule is generally put in place for most users; however, there are times where exceptions are required for specific individuals. Rules can be configured to allow or disallow exceptions. Once an exception request is approved, the resources being applied for the exception are assigned to the user, overriding the segregation of duties rule.
To disallow exceptions, you enable the Exceptions not allowed option on the page. You can also write a plugin to override this setting, to allow exceptions in certain circumstances. You enable the plugin in the Program to enable exception field.
Requirements
See Writing plugins for general requirements.
Shipped plugins
A sample plugin script, plugin-sod-exception.psl
, is provided in the samples\ directory. The sample always returns success, to override the Exceptions not allowed setting. You must edit the script and move it to the \<instance>\plugin\ directory.
Execution points
The exceptions plugin is run when a user views SoDs on a self-service request page or certification page.
Input
The plugin receives the ID of the SoD and the requester:
"" "" = { "sodid" "" = { "sodid" = "<SoD ID>" # indicates the ID of the SoD rule that is in violation } "user" "" = { "user" = "<userid>" # indicates the userid of the user that is in violation of # the SoD rule. This value will be blank for new user # requests that violate the rule since it is not yet known # until after the request is submitted. } }
When a request for new users results in an SoD violation being triggered, the value for the user ID for the "user" section will be blank since it is not known at this point of the request (it is determined after the request is submitted).
Output
The plugin returns standard output where retval=0 means that the Exceptions not allowed setting is overruled; for example:
"" "" = { "errmsg" = "<text message>" # The message to indicate why an exception may be allowed or # disallowed. "exception" = "<true|false>" # Mandatory; true indicates that exceptions may be allowed. # Anything else (such as false for example) will not allow # exceptions to be requested. "retval" = "0" # Mandatory; non-zero indicates that exceptions may not be # allowed. }