UserResolution

Sample workflow for handling privilegeResolution. Checks for expired users and assignments, applies provisioning rules for given users and does a user resolution.

UserResolution is the Java-based real-time workflow for resolving a single user’s current privilege set. When a dxrUser entry changes — for example because an assignment is added or removed, or because a role or group it depends on is updated — the Java-based Server creates a ProvisionTS request that this controller workflow picks up. The PrivilegeResolutionActivity checks for expired users and expired assignments, applies the configured provisioning rules to the user, recalculates the complete privilege set, and writes the resulting account and membership changes to the target system subtrees.

The workflows in this reference are delivered as factory data and are loaded into the Connectivity configuration database during the initial configuration. They are samples: use the Identity Manager to copy a workflow into your own scenario and adapt the copy. Do not change the delivered objects, because a product update can replace them.

At a Glance

Name

UserResolution

Prerequisites

Copy the workflow into your scenario and activate it in the Java-based Server.
Set provisionrulesroot and usersubtree to the correct DN paths for your domain before activating.

Workflow and Activities

Activity Type Component description Description Ports

Activity	Type	Component description	Description	Ports
`error`	`error`	`provisioningActivity`	Error Activity	`Message`
`join`	`PrivilegeResolutionController`	`PrivilegeResolutionActivity`	Activity for user resolution and account update.	-

error

provisioningActivity

Error Activity

Message

join

PrivilegeResolutionController

PrivilegeResolutionActivity

Activity for user resolution and account update.

Ports

Activity Port Component description Connector Connected directory Bind profile SSL

Activity	Port	Component description	Connector	Connected directory	Bind profile	SSL
`error`	`Message`	`errorPort`	`ErrorNotifyMailConnector`	-	-	not set

error

Message

errorPort

ErrorNotifyMailConnector

not set

Configuration Parameters

Table 1. Workflow parameters of `UserResolution`
Parameter	Default value
`timeout`	P0Y0M4DT0H0M0S

Table 2. Parameters of activity `error`
Parameter	Default value
`resourcefamily`	LDAP
`retrylimit`	3
`timeout`	P0Y0M1DT0H0M0S
`waitbeforeretry`	P0Y0M0DT2H0M0S

Table 3. Parameters of port `Message` (activity `error`)
Parameter	Default value
`decrypt.attribute`	dxmPassword

Table 4. Parameters of activity `join`
Parameter	Default value
`provisionrules.batch.accumulator.size`	500
`provisionrules.cache.mru.size`	10000
`provisionrules.cache.prefetch.size`	300
`provisionrules.ldap.pagesize`	300
`provisionrulesroot`	cn=domain_name,cn=Rules,cn=Policies,cn=domain_name
`resourcefamily`	ConsistencyCheck
`retrylimit`	3
`timeout`	P0Y0M0DT0H15M0S
`usefilterdirectly`	FALSE
`userstorage.batch.accumulator.size`	500
`userstorage.cache.mru.size`	10000
`userstorage.cache.prefetch.size`	50
`userstorage.ldap.pagesize`	50
`userstorage.useusercache`	TRUE
`usersubtree`	cn=subtree,cn=Users,cn=domain_name
`waitbeforeretry`	P0Y0M0DT0H30M0S

A Java-based real-time workflow runs as a permanently loaded configuration in the Java-based Server (IdS-J). It is triggered by a request or an event rather than by a schedule. Each workflow consists of activities; an activity opens one port per system it talks to, and each port uses a connector to reach that system.

Most provisioning workflows contain a join activity that performs the actual work and an error activity that receives requests which still fail after all retries and sends a notification about them. The retrylimit, waitbeforeretry and timeout parameters of an activity control how often and how long a failed request is retried before it is handed to the error activity.

The event port publishes change events over JMS, and the notify port sends e-mail notifications. Neither port is bound to a connected directory.

The workflow has two activities. The join activity uses the PrivilegeResolutionActivity component with the PrivilegeResolutionController type to process the resolution request. It reads provisioning rules from provisionrulesroot, caches them with the page sizes and MRU sizes configured by the provisionrules. parameters, and looks up the user in usersubtree using the userstorage. cache settings. The retrylimit is 3 with a waitbeforeretry of 30 minutes. Failed requests are forwarded to the error activity for e-mail notification through the Message port.

Operation

A change to a dxrUser entry causes the Java-based Server to create a ProvisionTS request for the dxrUser controller type.
The Java-based Server assigns the request to the join activity of this workflow; up to timeout (4 days) is allowed for the workflow instance to be picked up.
The PrivilegeResolutionActivity checks whether the user or any of their assignments has expired, and expires them if necessary.
The activity applies the provisioning rules loaded from provisionrulesroot and recalculates the user’s complete privilege set.
Account and group membership changes resulting from the resolution are written into the target system subtrees of the Identity Store.
If the activity fails, it is retried up to three times with a 30-minute wait between attempts. Requests that still fail after all retries are handed to the error activity for e-mail notification.
The workflow is delivered inactive (dxmActive is FALSE). Copy it into your own scenario, set the DN placeholders in provisionrulesroot and usersubtree, and activate the copy.