Follow-on Tutorials

A description of the sample connectivity scenario (its elements and its environment) on which the tutorial is based

A summary of the tasks required to integrate the sample connectivity scenario into DirX Identity for each integration level

The level 1 integration of the sample connectivity scenario (simple execution)

The level 2 integration of the sample connectivity scenario (central edit)

The level 3 integration of the sample connectivity scenario (detailed customization)

Click Provisioning → Privileges. You’ll see folders for Roles, Permissions and Groups.

Click Edit to open the HR2Ident workflow for editing.

Double-click the beginning of the top-most job entry in Workflows/Jobs.

Three buttons are displayed at the end of the job entry.You can view the job with the first button, delete it with the second button and change the reference to another job with the third button.Click the first button.

The job object is opened with all its tabs.Click through the different tabs and view their content.

Click the Job tab again and change Timeout to 01:00:00.This action affects the automatic abort feature of DirX Identity.Now your job can run for 1 hour (the default was 2 hours) because you are sure that the amount of data can always be handled in this timeframe.

Do not change anything else.Click OK to close the job object and then Save to exit the edit mode of the structure view.Click Close to close the structure view window.

Log in to DirX Identity Manager’s Provisioning view group.

Click Domain Configuration → My-Company.

In the Compliance tab, click Edit.

Check Segregation of Duties (SoD) checks if it isn’t already checked.

Click Save.

Click File → Exit to close your Manager instance(s).

Start Manager again and log in to the Provisioning view.

In Provisioning → Policies, click SOD Policies → My-Company → Contractor <> Manager.

Click Edit, and then check Is active.

Click Save.

When enabling the SoD policy, DirX Identity checks whether there are already violations for this policy. In our example, there are no violations found.

In Provisioning → Privileges, click Roles → Corporate Roles → General → Manager. Look at the Approval tab. You can see that Potential SoD conflict is checked.

Click the role Contractor. You can see that this role also has Potential SoD conflict checked.

In an Internet browser, start DirX Identity Web Center.

Log in as Taspatch Nik with the password dirx.

In Users → Select user, enter P in Search for, and then click Search to return a list of users whose names begin with "P".

Select Pitton Lavina from the list. Web Center displays a user summary for Lavina.

In the Users menu, click Assign privileges.

Enter M in Search for, and then click Search to return a list of roles that begin with "M".

Check Manager, and then move it to Assigned roles.

Click Save. Web Center displays a warning dialog that identifies the Manager <> Contractor SoD violation.

Click Save anyway.

Switch to DirX Identity Web Center and click Logout to log out of Nik Taspatch’s account.

In the Log in dialog, enter Hungs Olivier in Name and the password dirx.

Click Work List → Task list. Olivier Hungs task list is displayed.

Click the Pitton Lavina → Manager task.

Enter L. Pitton is a substitute manager for 6 months in Reason and then click Accept.

There is nothing more to do, so click Logout.

The InitializeReapproval workflow, which examines all assignments of privileges marked for re-approval and sets their end date or period attributes.

The StartReapprovalWorkflows workflow, which starts the request workflow that has been configured for the privilege that requires re-approval. In the sample domain, the 4 Eye Approval request workflow is the default workflow to be run for any privilege assignments that require re-approval if no other workflow is configured.

In Provisioning, select Privileges → Roles → Corporate Roles → General and click Trainer to select it.

Click Edit.

Check Requires re-approval in the Certification tab.

In Re-approval period, enter 5 in Day(s). Now all assignments of the Trainer role are scheduled to expire in 5 days unless they are re-approved.

Click Save.

Click Provisioning → Privileges → Roles → Corporate Roles → General.

Right-click Trainer, and then click Report.

Click Number of users per role in the list of report templates.

Check Output to viewer, and then click Run report. After a few seconds, DirX Identity Manager displays a report on the number of users who are assigned the Trainer role. You can see that 5 users are affected by the role and 4 are direct users. Re-approval will affect only the direct users. If you have followed the getting started tutorial, you will see 6 affected users and 5 direct users.

Click Close to close the report.

Right-click Trainer again, select Report. Now click Users of a role in the list of templates and check Output to viewer. After a few seconds, DirX Identity Manager displays a list of the users who are affected by the Trainer role. They are: Straub Hatty in Sales, Costello Marcella and Blander Dyan in Professional Services, Kubalke Leo in Product Testing and Telfer Laura in Human Resources. If you have followed the getting started tutorial, you will see Teacher Mark as well.

Note that Costello Marcella will not be affected by the re-approval process since she is an affected user of the Trainer role but not a direct one. This will be explained in greater detail at the end of this chapter.

Click Close to close the report.

Return to the Manager window, click Connectivity, and log in if necessary.

In Global View → My-Company → Main, right-click the workflow line between the two Identity Stores.

Select InitializeReapproval and then click Run. After a few seconds, the workflow should complete successfully. (The InitializeReapproval activity is displayed in green in the Structure tab.)

Click Close.

Click Provisioning → Users → My-Company → Human Resources → Telfer Laura.

Click Assigned Roles and look at the Trainer role in the list. Notice that End date now shows a date at which the role must be re-approved (five days from today), and Reapproval is checked.

Return to the Manager window and click Connectivity.

In My-Company → Main, right-click the workflow line between the two Identity Stores, select StartReapprovalWorkflows, and then click Run. After a few seconds, the workflow should complete successfully. (The StartReapprovalWorkflows activity is displayed in green in the Structure tab.)

Click Close.

In Provisioning, select Workflows → Monitor → Queries → Running Workflows. You can see that there are 4 (or 5) workflows, one for each user who is assigned the Trainer privilege. These workflows were started because the Trainer role is set to expire in 5 days, which falls within the 14-day approval period specified for starting re-approval workflows.

Click Telfer Laura → Trainer. You can see from the General tab that there are two activities in grey - Approval by User Manager and Approval by Privilege Managers. This is the 4-Eye Approval workflow we’ve discussed in "Adding a User".

Right-click Approval by User Manager, then click Open.

Click the Status Information tab. Look at the Participant field. You can see that the approvers are Berner Hans, who is Laura’s manager, and Ormsby Mary-Jane, who is representative of Hans. The workflow has automatically notified them about the re-approval task, as it has the managers and their representatives of all the other affected users.

Click Close to return to the General tab. Right-click Approval by Privilege Managers and then click Open.

Click the Status Information tab and look at Participant. The re-approver here is Costello Marcella, the owner of the Trainer role.

In Web Center, log in as Costello Marcella with the password dirx.

In Work List, click Task list. You can see that Marcella has 5 (or 7) tasks in her queue: one for each user who needs his Trainer role re-approved since she is the role owner; and an additional task since she is the manager of Blander Dyan. She needs to accept each of these requests for these users to retain their Trainer roles. If she rejects any of these requests, the workflow automatically notifies the affected user that his role assignment has been rejected, and DirX Identity will remove the role assignment.

Click Self Service → Display summary, and then click on the Roles button.You’ll see that Marcella has the Training Manager role.Let’s take a look at this role in more detail.

Click Roles → Select role.

Enter T in Search for, and then click Search to get a list of roles that begin with "T".

Select the Training Manager role and look at Privileges.You can see that the Trainer role is listed in Assigned junior roles, which means that Training Manager automatically inherits the Trainer role.This is the reason why Marcella appears in the role report as an affected user but does not need her Trainer role re-approved: since she has the Training Manager role assigned to her, she automatically gets the Trainer role.

Logout and close the Internet browser.

Creating and configuring a certification campaign in the Provisioning view by providing a start date, an approval period, a search criterion for users to be certified and a search criterion for privileges to be certified.

Enabling the Certification Campaign Controller workflow in the Connectivity view.

Setting up a schedule for the Certification Campaign Controller workflow as a regular task.

Configuring the SMTP service

Setting up a schedule for the Certification Campaign Controller workflow

Creating a thread for the Certification Campaign Controller workflow in the Java-based Server

Configuring the Certification Campaign Controller workflow

Start DirX Identity Manager and log in to the Provisioning view group.

To create the certification campaign, select Provisioning → Certification Campaigns. Right click the Certification Campaign folder and the select New → Certification Campaign.

In the General tab:

In the Status tab:

In the User filter tab:

In the Privilege filter tab:

In the Global View of the Connectivity view group, select the workflow line between the two Identity Store connected directories.

Select the CertificationCampaignController workflow and then select Run from the context menu. The workflow starts the campaign and creates the necessary certification tasks in the campaign folder.

Go to the campaign entry Tutorial Privilege Certification and select the Status tab.

Click Edit and change Due Date to today.

Click Save to commit the changes.

Run the CertificationCampaignController workflow in the Connectivity view.

For users Kubalke Leo (Product Testing) and Straub Hatty (Sales), the role Trainer was removed.

For users Blander Dyan (Professional Services) and Telfer Laura (Human Resources), the role Trainer is assigned.For user Telfer Laura, the role is set to be removed after current date + 3 days.

Creating the certification campaign. A campaign entry is created and configured with all mandatory attributes.

Running the certification campaign. After the campaign is started, the certification tasks are created. The approvers are notified and they must certify - approve or reject - privilege assignments.

Applying the results after the campaign is finished. Depending on the configuration, the rejected and/or ignored privilege assignments are deleted. The certification owner can run a report to document the certification result.

Physically deleting all the campaign entries from the Identity domain after the configurable status expiration date is reached.

Make sure the SMTP service is configured (it’s required for sending the campaign notifications): In the Provisioning view, browse to Workflows → Configuration → Services →SMTP. In SMTP host, provide an appropriate SMTP host address (for example, localhost if you have a local SMTP server). For the purpose of this tutorial, you can update the Map mail address field. Enter dummy to suppress all notification emails or enter a specific email address; for example, your own address to send all the notifications to your mailbox rather than to the calculated ones. Note that you should clear this field in a production environment.

Set up a schedule for the Certification Campaign Controller workflow. For the purpose of this tutorial, we do not need a schedule for this workflow, because we’ll start it manually. For production, you should configure a schedule for the workflow and make sure that it runs at least once a day.

Make sure the Java-based Server starts one thread for the Certification Campaign Controller workflow: In the Connectivity view, browse to Configuration → DirX Identity Servers → Java Servers → My-Company → My-Company-S1-*yourhost. Click *Edit. In the Resource Families tab, move CertificationCampaign from Available down to Selected. Change the number of threads to 1. Click Save.

Configure and enable the Certification Campaign Controller workflow: In the Connectivity Global View, select the My-Company scenario. Select the workflow line between the two Identity Store connected directories and then select New from the context menu. After you have selected the Certification Campaign Controller workflow, the workflow wizard starts and guides you through the configuration options. In the first step, make sure you check Is Active. You also need to set the Cluster and Domain fields. For this tutorial, it’s sufficient to specify * for both fields. After the last step, click Finish to save the new workflow in the My-Company scenario.

In the General tab:

In the Status tab:

In the User filter tab:

In the Privilege filter tab:

Click OK to commit the changes.

Campaign Start - this notification will be sent to the Certification Campaign owner, who is the user Hungs Oliver, when the Certification Campaign starts. The email contains information about campaign such: name, description, start date, due date, and other information.

No Approver - this notification will be sent to the Certification Campaign owner (by default) right after the campaign starts and all certification entries are created. The email contains a list of certifications which are not started (RUNNING state), and are moved to failed prepare (FAILED.PREPARE state). The reason for this notification is the missing manager field for the subject of the certification (the manager attribute in LDAP). The email recipient can use this content to fix the failed prepared certification and then restart them. We’ll describe how to do this in the next sections.

Approval Start - this notification will be sent to all Certification Campaign participants with the approver role. The email is sent at the start of campaign and contains the list with certifications to be approved (simple and attributed assignments). This email is sent once; during the approval period, the Approval Remind notification is used.

Perform a manual privilege assignment that can easily be rejected in the campaign: In Provisioning → Users, assign the role Test Tasks to the user Bellosa Marco in the folder Customers → Mercato Aurum.

Modify the preferred language of Hungs Olivier to English: in Provisioning → Users → My-Company → Hungs Olivier → Communication, set Preferred Language from German to English so that notifications regarding the certification campaign are sent in English. Make sure you record the previous value for this field before you modify it. You will need to reset Hungs Olivier's preferred language to this value at the end of this tutorial to avoid side-effects when running other tutorials.

A warning for user Bellosa Marco. The Certification Campaign Controller workflow didn’t find an approver for this user and the state of the certification task is set to FAILED.PREPARE. Note that the default implementation selects the manager of a user as the approver.

A warning for user Maskery Guy for the same reason.

Because Status Expiration Date was not set at the start of campaign, a default Status Expiration Date will be calculated at the end of the campaign and will be End Date plus 30 days.

The certification for Abele Marc is running correctly with Dalmar Christopher as approver, with DXR Auditors as Simple Assignments.

The certification for Bellosa Marco is in status FAILED.PREPARE. The reason is explained in the Log entry of the Status tab: this user does not have a manager and therefore no approver was found. To fix this problem, click the Edit button. In the Approvers list in the Approvers tab, select Hungs Olivier. In the Status tab, change the Status to RETRY.PREPARE and then click Save. Now run the Certification Campaign controller again. Certification changes to RUNNING status.

The certification for Dalmar Christopher is running correctly with Hungs Olivier as approver.

The certification for Maskery Guy is in status FAILED.PREPARE. The reason is explained in the Logs entry of the Status tab: this user does not have any manual assignments. Automatic assignments, such as inherited or obtained by provisioning rules, are not certified.

A Campaign Start notification for the campaign owner; in our tutorial, this is Hungs Olivier. This email contains details about the campaign such as: User Filter Base, User Filter, Start Date, Due Date, and so on.

A No Approver notification for campaign owner; in our tutorial, to Hungs Olivier. This email informs about users without approvers; in our tutorial, Bellosa Marco and Maskery Guy.

Two Approval Start notifications for approvers Hungs Olivier and Dalmar Christopher. These emails contain details about the campaign and about certification tasks subjects (the users to be certified), their Attributed Assignments and Simple Assignments.

Go to the campaign entry Tutorial User Certification and select the Status tab.

Click Edit and change Due Date to today.

Click Save to commit the changes.

Run the CertificationCampaignController workflow from the Connectivity view group.

In the Provisioning view group, select the Certification Campaigns view and then select the campaign Tutorial User Certification.

Underneath the campaign container, browse to the certification for Bellosa Marco. The Approvers tab shows Hungs Olivier.

The Attributed Assignments tab is empty. Bellosa Marco had no assignments with either role parameters or end date.

The Simple Assignments tab shows that the Test Tasks role has been rejected.

Navigate to the user Bellosa Marco in the folder Customers → Mercato Aurum and check that the role Test Tasks has been removed.

Return to the Tutorial User Certification campaign and select the certification for Dalmar Christopher.

All assignments in the tabs Attributed Assignments and Simple Assignments are in the Not Certified list. If you check the user entry in the folder My-Company → Finances, you’ll see that all these assignments still exist. This is correct because the Revoke privileges settings field in the campaign requested to remove only the rejected assignments and leave the assignments that were not certified as they are.

In the Provisioning view group, select the Certification Campaigns view and then browse to Tutorial User Certification.

Right click the campaign entry and then select Report from the context menu.

Select the report Campaign with all properties.

Set the following fields:

Click Run report.

Browse to the location where the report was saved and open the generated HTML report with your favorite web browser. You will see something like this:

In the Provisioning view group, select the Certification Campaigns view and then browse to Tutorial User Certification.

Select the Status tab and then set Status Expiration Date to a date in the past (for example, yesterday).

In the Connectivity view group, navigate to the workflow CertificationCampaignController (Workflows → My-Company → Main → Identity Store) and then run it via the context menu.

Return to the campaign in the Provisioning view group.You’ll see that the campaign Tutorial User Certification is now in the state Campaign is marked for deletion (DELETED).This state is handled by the DirX Identity cleanupObjects workflow, which also evaluates the cleanupDeletedCertificationCampaigns rule from Provisioning → Policies → Rules → Default→ Consistency.

Log in to DirX Identity Manager’s Provisioning view group.

Click Domain Configuration → My-Company.

In the RequestWorkflows tab, click Edit.

Check Attribute modification approval, if it’s not already checked.

Click Save.

Click File → Exit to close your Manager instance(s).

Start Manager again and log in to the Provisioning view.

In Provisioning → Policies, click Attribute Policies → My-Company → User - Location and Organization.

In the General tab, click Edit, and then check Is active if it’s not already checked.

Click Save.

Click the Configuration tab. You can see the attributes that require approval listed in the Selected box. The Available box lists additional attributes you can select to require approval.

In an Internet browser, start DirX Identity Web Center.

Log in as Taspatch Nik with the password dirx.

In Users → Select user, enter B in Search for, and then click Search to return a list of users whose names begin with "B".

Select Baretti Franca from the list. Web Center displays a user summary for Franca.

In the Users menu, click Modify user data.

Change the location to My-Company San Jose in Location.

Click Save. Web Center displays Franca Baretti’s entry again.

First note that the location in Franca Baretti’s summary page is still My-Company Rome. But the page now includes a modification order list which shows that the modification is in approval (Since it may take some time to start the approval workflow, you may have to click the Refresh summary icon in the page repeatedly before you see the item.)

Now click Show subscription status in the Users menu.

The Select a Workflow page lists a workflow for Franca Baretti with the status Running. Click it.

Franca Baretti’s attribute modifications require approval from a member of My-Company’s Human Resources department. In Running activities, you can see the members of this department. Only one of these members needs to approve the request.

There is nothing more for Nik Taspatch to do, so click Logout.

Log in to DirX Identity Manager’s Provisioning view.

Click Workflow, and then click Workflow → Monitor → My-Company → Users → Modify Location and Organization. In a production environment, this folder contains sub-folders named with dates; for example, 2016-10-04. Each sub-folder contains status information about the request workflows that have executed on these dates.

In our case, we have one folder with today’s date. Click this folder, and then look for Baretti Franca in the list of workflows (it should be the only one there). Click it. In the General tab, Manager displays a graphical representation of the request workflow that is processing Franca’s attribute modification approval. The step Approval of Attribute Modifications is highlighted in grey to indicate that it is the activity that is currently being processed. You can double-click this step, and then click the Status Information tab. You can see the same participant list of Human Resources members who are allowed to approve the request.

Start the Web Center.

Enter Berner Hans in Name and the password dirx. (Remember that all persons in the sample domain are set up to have the same password.)

Click Log in (or press RETURN) to log in.

In Work List, click Task list and select the approval task. Web Center displays Franca Baretti’s data in the "Approval of Attribute Modification" dialog.

Enter F. Baretti transfer to San Jose, U.S. of America in Reason. (It’s good practice to provide a reason for your decision, especially if you reject a request.)

Click Accept to grant the request.

Note that Task list is now empty.

There is nothing more to do, so click Logout.

Enter Taspatch Nik in Name and the password dirx. Click Log in or press RETURN.

In Users → Select user, enter B in Search for, and then click Search to return a list of users whose names begin with "B".

Select Baretti Franca from the list. The Display summary page is shown. Check that the location has now changed to My-Company San Jose. Also note that country and postal address have been changed accordingly since these attributes are mastered by location.

Select the Groups button near the bottom of the page.

Check that the Windows groups and accounts have moved from Windows Domain Europe to Windows Domain US (the assignments still exist, but are in the state DELETED or DISABLED).This shows that DirX Identity automatically re-configures the IT resources that Franca Baretti requires.

Click the Users → Show subscription status icon in the toolbar and then click the button Succeeded Workflows.The Select a Workflow list shows the workflow for Franca Baretti with the status Succeeded.Click the workflow.The Finished activities section shows the results of the approval.

There is nothing more to do, so click Logout.

In the Provisioning view group, click Workflows, and then click Workflows → Monitor → My-Company → Users → Modify Location and Organization → today’s date → Baretti Franca.

Double-click the Approval of Attribute Modifications-0 step, and then click the Status Information tab.Here you can see that the approval request workflows for the other Human Resources members were successfully finished, since one member accepted the attribute modification.

Log in to DirX Identity Manager’s Provisioning view group.

Click Domain Configuration → My-Company.

In the Compliance tab, click Edit.

Uncheck Segregation of Duties (SoD) checks.

Click Save.

Click Provisioning.

Select the user cn=Briner Ruben,ou=Sales,o=My-Company,cn=Users,cn=My-Company.

Click Edit.

Scroll down to the employeeType attribute and change its value to Contractor.

Set the dxrTBA attribute to true. You can use this flag later on to indicate to DirX Identity services (policy execution and privilege resolution) that only users with this flag need to be managed (after working on these objects, the services reset the flag). If you do not use this flag, you must run the services on the entire user population, which might be a time-consuming procedure with a high load on the Provisioning configuration server.

Save the user object.

Select the user Briner Ruben from Provisioning → Users → My-Company → Sales.

Click the General tab and then refresh the entry. The Employee Type field displays Contractor.

Verify that the To be analyzed flag in the Operational tab is set (this is the dxrTBA flag).

Check that the user has the Internal Employee role assigned; this is inconsistent with the changed employee type. To correct this problem, we run the policy execution service and a subsequent privilege resolution.

Click Provisioning and then click Target Systems.

Right-click Target Systems (the top-level object in the tree) and then select Connectivity → Workflows → PolicyExecution → Configure Workflow. The workflow wizard opens.

Click Next. You can see that the policy execution service does not perform a privilege resolution automatically (Provisioning Mode is set to Assign Privilege only). Do not change this step. Click Next again.

Change Base Object to cn=Role based scenario,cn=My-Company,cn=Rules,cn=Policies,cn=My-Company if it is not already set to this value. This setting indicates that we run all policies below this node.

Change Search Filter to (objectClass=dxrProvisionRule) if it is not already set to this value to specify that we use only provisioning rules in this run.

Click Finish to close the wizard.

Right-click Target Systems and select Connectivity → Workflows → PolicyExecution → Run Workflow to run the workflow. Wait until the workflow has completed.

Click the Structure tab and then the activity in the middle. A new window opens. Click the Trace tab and then check the trace file (click the line and then the button to the right).

At the tracing level set for the workflow, the trace file contains only brief statistics. Each privilege that has been processed is listed in a table with the number of subjects processed and the corresponding errors and warnings. In this case, the privileges Contractors, Internal Employee and Signature Level 1 each have processed one subject (user). This must be our Ruben Briner, because all other users in the database were not changed, and so the policy execution service had nothing else to do.

Note that assignment of permission Signature Level 1 failed since we’ve stopped the Java-based server. Let’s ignore this for this tutorial chapter.

Close the trace window and the Policy Execution and Run Workflow windows.

Select the user Briner Ruben from Provisioning → Users → My-Company → Sales.

Click the Assigned Roles tab and refresh the entry. The Contractor role should be visible.

Click the Assigned Permissions tab and refresh the entry. The Contractor permission is not yet visible because the privilege resolution service did not run. For the same reason, the Internal Employee permission is still assigned.

Select the Target Systems view.

Right-click the Target Systems top-level node and select Connectivity → Workflows → PrivilegeResolution → Run Workflow to run the privilege resolution workflow. Wait until the workflow has completed.

Click the Structure tab to check whether the workflow has performed successfully. The workflow activity PrivilegeResolution must be displayed in green.

Close the Run Workflow window.

Click the Assigned Permissions tab.Now the Contractor permission is visible (you may need to click the refresh button first).

Click the Assigned Groups tab.Several new group assignments have been created.Note that a new Contractor group is visible (Windows Domain USA) as well as the Contractor Portal group in the Intranet Portal target system.

Click Connectivity, and then click Expert View.

Open Workflows → Default → Source Scheduled. The workflow ODBC2Ident+Maintenance is exactly what we need.

Select this object and then select Copy Object. Set the name to NewHR2Ident+Maintenance and click OK.

The location of the copied object is not correct. Select Move Object and set Workflows → My-Company → NewCompany → Source Scheduled → ODBC as the target. Click OK and wait until the move is performed. DirX Identity checks and adapts all references pointing to the moved object to guarantee the integrity of the Connectivity configuration, so this action requires some time.

Open the previously selected target path for the move operation. The new workflow NewHR2Ident+Maintenance is visible there.

Click it and open it. Three activities are visible but they point to the wrong (default) objects. Adjust them to make the workflow usable for the My-Company scenario.

Click the Creation Workflow activity in the left pane and then Edit. Click the last icon behind Run Object (…​). A tree browser opens and you can see that this activity references the default ODBC2Ident workflow. Select Workflows → My-Company → NewCompany → Source Scheduled → ODBC → NewHR2Ident instead and click Save.

Click the Policy Execution activity and link it to Jobs → My-Company → Main → Identity Store → Policy Execution. Click Save.

Click the Privilege Resolution activity and link it to Jobs → My-Company → Main → Identity Store → Privilege Resolution. Click Save.

Click Global View and select the scenario My-Company → NewCompany.

Right-click the workflow line, then select Assign.

Select the NewHR2Ident+Maintenance workflow from the list and click OK.

Creating a new target system of type RequestWorkflow in the Target Systems view that reflects your offline system that is to be manually provisioned. This step adds the necessary Java-based workflow that starts the corresponding request workflow for each change to the target system.

Setting up the necessary groups in your target system or loading them from the offline system.

Copying the provided request workflow template, modifying it to your requirements and then configuring the Java-based workflow you copied to use this request workflow definition.

A documentation archive in Munich

Three data center rooms in Berlin, Frankfurt and Munich.

Log in to Web Center as Wagner Retha.

Execute Work List → Task list from the menu bar.

You can see a work item that requests the account creation.

Click the item to view the details (Addition by Administrator). It shows that an account for Bill Sedran is to be created and added to the Munich - Archive group. All of the required attributes are shown.
Note that these attributes are defined in the mapping of the corresponding real-time workflow. So you can add or remove attributes as they are needed. You can also define the sequence of the attributes in the mapping definition.

Retha now must open the administrative interface to the Physical Access system and add the account as requested. After successful creation, she can add a reason and then click Accept. If she wants to do the task later, she can press Do later. Clicking Reject means that she cannot do the task. In this case, it makes sense to add a reason. This action only sends a notification to the user that the task failed. The DirX Identity target system and the external system are not in sync which is visible because the target system state is still NONE.

We assume that Retha can add the account to the Physical Access system, so we acknowledge it by clicking Accept.

The work list is now empty.

Creating objects

Modifying objects

Deleting objects

Assigning privileges

Removal of privileges

Login to the Provisioning view group of the DirX Identity Manager.

Click the Users view and then navigate to Users → My-Company → Product Testing.

Select Leo Kubalke and then click the General tab.

Click Edit and enter Dr. into the Title field.

Enter today’s date into the Due Date field (to the left of the Save button).

Click Save.

If not yet done, click the entry of Leo Kubalke.

Click the Orders tab. If it is still empty, perform a refresh (on Windows: F5). Be patient until the data appears.

You can see the order with the due date (the current date), the attribute name title, the empty old value and the new value 'Dr.'.

Select the Tickets view.

Navigate to Tickets → Internal → Users → date → Kubalke Leo time and click this entry.
DirX Identity stores all of its self-created tickets in the tree Internal. The next level divides the object types, in this case we have a Users folder. Below this folder you can find a folder for each date (this is the due date). This allows easily finding out all tickets that are valid for a specific date and you can also see that for a specific date no tickets exist if the corresponding folder is missing.

In the General tab of the ticket, you can see the Name (Kubalke Leo time), the Object type (here dxrUser) and the Operation (here MODIFY). The creator of this ticket is shown as the Owner (in this case the Domain Admin). The Subject field shows the DN of the object the ticket is valid for. Because the Request workflow field is empty, there is no related approval in progress.

Check the Status Information tab. The Status field shows Input.Completed, which means that the ticket is ready to process. You can also see the Due date here. The Expiration date and Delete date are still empty. If any errors occur, for example, during ticket processing, the Error field shows this information.

In the Object tab, you can find the order (the change definition) for the object itself (for the subject). It is identical to the previously viewed Orders tab at the user entry.

Click the Assignments tab to see that this ticket does not have any assignment order.

Open the _Queries folder. At the top level, you can find a set of general queries.

Click Active Tickets to see our active ticket for Leo Kubalke.

Because there are no error tickets, clicking Error Tickets does not show any entries.

Click the Variable Time Constraint query. A dialog appears that shows by default a three-hour time period for modifications and creations. You could change these values, but in this case, we accept them and simply click OK. Again we can see the Leo Kubalke entry.

There are some additional folders that help to evaluate specific types of tickets. Open For Object Types and click Users. Our entry is shown again.

Opening For Operation Types and clicking Modify reveals the same entry.

Now open For Status and click Input.Complete to see the same entry.

Login to the Connectivity view group of the DirX Identity Manager.

Click Global View and then navigate to My-Company → Main.

Click the line between the two Identity Store icons and select Process Internal Tickets → Configure from the context menu.

Click through the two tabs. There is nothing interesting to see besides the fact that this workflow runs with Resource Family Event_Maintenance, which means it runs in the Java-based server and does not run as an external executable in the C++-based server.

Now run the workflow (select Process Internal Tickets → Run from the context menu.

Log in to the Provisioning view group of the DirX Identity Manager.

Click the Users view and then navigate to Users → My-Company → Product Testing.

Select Kubalke Leo and click the General tab. You should see the value Dr. in the title field. This shows that the ticket was processed.

Click the Orders tab. The tab is empty.

Click the Tickets view.

Navigate to Tickets → Internal → _Queries and then click the Processed Tickets query.

The Kubalke Leo ticket is found.

Click the Status Information tab.

The Ticket state is now ApplyChange.completed and the Delete Date is set to one month later.

Click the Domain Configuration view and then the top-level object with the name of your domain.

Select the Timing tab.

In this tab, you can find global settings for the Ticket life time of successfully processed tickets and erroneous tickets.

Creation of a new user optionally with already assigned privileges.

Modification of a user, which means either attribute changes or changes of the assigned privileges.

Deletion of users.

Creation, modification and deletion also apply for other object types like roles, permissions or groups.

Setting up a Web service that is derived from the delivered sample web service that consumes tickets, converts them to Identity internal order representation and starts with that order the corresponding request workflow.

Copying the provided ticket processing request workflow and adapting it as required. You can set up one or more of these request workflows for each type of object.

Copy the complete folder Additions\ServiceMM\WorkingWithSourceTickets on your DVD to any location on your machine (for example C:\SampleTicketWS).

Make sure your PATH variable is set appropriately to find the correct version of the program java.exe.

Start the sample ticketing Web Service. There are two possibilities:

Starting the Web Service as stand-alone application

Deploying the Web Service into Tomcat

Check the setting of the variable ENDPOINT in the file seturl4client.bat regarding the port number. The file shipped with the product is correct if the related port is 8080. If the correct port is not 8080, then the setting must be corrected so that it contains the correct port - either the port used when starting the service via runServer.bat or the actual Tomcat port, respectively.

The request contains a requestID (value Request-1) that is important because you need it later on to refer to the sent request if you request the status of it. Typically this ID is generated by the generating service management system or it is equal to the ticket number in that system.

The spml:identifier is of type DN and defines the object to create with its path:*
cn=Irwin Dough,ou=Professional Services,o=My-Company,cn=Users,cn=My-Company*

The spml:operationalAttributes section defines operational attributes:*
directoryType=dxrUser* - defines the object type to create. This information is used to find the correct ticket workflow via the When Applicable section.*
operation=CREATE* - specifies the operation to perform on this object.*
creator=cn=DomainAdmin,cn=My-Company* - sets the initiator of the workflow. You can use it in the When Applicable section.

The spml:attributes section allows specifying all attributes of the user to create as there are for example the cn, objectClass, sn, givenName. You can also set links to other objects, for example manager, dxrLocationLink, dxrOrganizationLink, dxrOULink.

Note that we cannot set the dxrOULink to Professional Services because this would assign the Sales Task role to the user. This role includes SAP relevant groups that cannot be synchronized because the SAP R/3 system is not physically connected. This would cause ticket workflow that cannot end successfully.

Use the spml:addPrivilegeAssignment section to specify the privileges to add together with the user creation. In this case, we add two roles: Manager Analyst Relations and My-Company Newsletter. The first role must be approved later on, which is not visible here. Of course we could specify time restrictions or - if the role requires it - role parameters. But we keep it simple here. Check the other sample requests delivered with the product to see all features of this sample web service.

Double click the batch file CreateUserWithRoles.bat to run it. The client sends the XML request to the sample web service which starts a request workflow. This requires some seconds. Be patient.

A log file CreateUserWithRoles.log is written. Open it to see the result:

Log in to the DirX Identity Manager’s Provisioning view group.

Select the Workflows view and navigate to Monitor → My-Company → Service Management → Process Ticket → date → Irwin Dough.

Click the General tab to view the workflow progress.

You can see Add attributes and Apply order steps that are already completed. The sample web service converted the ticket into an Identity order that was passed to the ticket request workflow.

The first activity Add attributes added two fixed value attributes. To understand this, navigate to the workflow definition:*
Definitions → My-Company → Service Management → Process Ticket*.

Open this entry, click the Add attributes activity and then click the Parameters tab. You can see that the attribute employeeType is set to "Contractor" and the dxmOprMaster attribute to "Service Management".

Check the result in the workflow instance: click the Object tab. You should see all attributes from your ticket definition and additionally the two attributes that were set by the Add attributes step.

Click the Assignments tab. Here you should see the two requested assignments from the ticket definition.

The second activity Apply order performed a sequence of steps:

It created the user in the Identity Store at the requested location. Check that the user exists (Users → My-Company → Professional Services → Irwin Dough). Step through the tabs to verify that the attributes were correctly set. You can see that many attributes were set automatically through attribute mastering from the business object Location.

It performed a privilege resolution. Check the Assigned Roles, Assigned Permissions, Assigned Groups and Accounts tabs to see the result.

One role was assigned automatically and is already resolved (Contractor role via rule).

The role My-Company Newsletter was resolved immediately because it is not flagged for approval.

The role Manager Analyst Relations requires approval. Thus an approval child workflow was started from the parent (ticket) workflow.

You can check this workflow either directly under Monitor → My-Company → Approval → 4-Eye Approval → date → Irwin Dough→ Manager Analyst Relations or you can use the parent workflow as starting point.

Click the parent workflow instance again and then select the Child Workflows tab. You can see the started child workflow as a line in the table. Note that State and ApplicationState are empty for child workflows not yet finished. Click the line and then the icon right beside the table. The Manager navigates to the child workflow instance. You can view it and then return to the parent workflow (use the arrow button of the manager).

We check the configuration of the Apply order activity to understand the settings in more detail. Click this activity in the workflow definition and select the Parameters tab. The meaning of the flags is:

If Apply Subject Order is flagged, the activity analyzes the order and creates or modifies the object.

If Track Changes is checked, all account and group relevant changes that are caused by this activity are stored in a list of provisioning changes that can be used later on by the Wait for completed provisioning activity.

If Track Changes in Child Workflows is checked, then child workflows get the Track Changes flag checked. This setting forces the child workflow to propagate the list of provisioning actions to its parent. This means that the parent has a consolidated list of all changes that a Wait for completed provisioning activity can use.

Open the file sampleTickets/CheckStatus.xml for editing.

Change the status request so that the operational attribute correlationID is exactly the correlation ID of the response that was received from CreateUserWithRoles.xml request. The correct value is the value of CreateUserWithRoles.correlationId from the file CreateUserWithRoles.log.The correlationID is the identifier of the workflow.

Remove the xml-comment characters which enclose the operationalAttributes section. This ensures that the status is checked first via correlationID and then via requestID as fallback.

If not yet done, change the requestID value so that it is checkStatus-1 instead of Request-1. This way, the status request will only be successful in case of a correct correlationID in the request.

Save the file.

Run the prepared CheckStatus.bat batch file.

View the CheckStatus.log file.

CheckStatus.id=Request-1
Connecting to http://localhost:8080/sourceTicketing/sourceTicketingService
CheckStatus.result=URN_OASIS_NAMES_TC_SPML_1_0_PENDING
CheckStatus.correlationId=141cb8e7b72$7bcc

You can see the request ID in the first line. The third line shows the status: PENDING. This indicates that the ticket processing in DirX Identity has not yet completed.

The correlation ID in the fourth line is the internal ID of the ticket in DirX Identity.

Open the file sampleTickets/CheckStatusByRequestID.xml.

Note that the value for requestID is the same as for sampleTickets/CreateUserWithRoles.xml. Close the file.

Run the prepared CheckStatusByRequestID.bat batch file.

View the CheckStatusByRequestID.log file:

CheckStatus.id=Request-1
Connecting to http://localhost:8080/sourceTicketing/sourceTicketingService
CheckStatus.result=URN_OASIS_NAMES_TC_SPML_1_0_PENDING
CheckStatus.correlationId=141cb8e7b72$7bcc

You can see the request ID in the first line. The third line shows the status: PENDING. This indicates that the ticket processing in DirX Identity has not yet completed.

The correlation ID in the fourth line is the internal ID of the ticket in DirX Identity. You could use it alternatively to request the status, see the section "Checking the Ticket Status" above.

Log in to Web Center as Benetton Gianfranco.

Click Work List → Task list and click the relevant item.

Enter a reason and accept the request.

Log out and log in again as Bellanger Lionel.

Click Work List → Task list and click the relevant item.

Enter a reason and accept the request.

Log out of Web Center.

Log in to DirX Identity Manager.

Select the Workflows view.

Navigate to Monitor → My-Company → Approval → 4-Eye Approval → date → Irwin Dough → Manager Analyst Relations.

Click the General tab and verify that the workflow is completed. The Apply Approved Privilege Change activity is green.

Select the Request Workflows view and navigate to Monitor → My-Company → Service Management → Process Ticket → date → Irwin Dough.

Click the General tab. The Wait for child workflows activity is green (successfully completed) and the Wait for completed provisioning activity is either in progress or also green (successfully completed). If not, wait until the activity and the workflow are complete.

Run the prepared CheckStatus.bat batch file again.

View the CheckStatus.log file:

The third line shows that the ticket could be processed correctly.

In DirX Identity Manager, select Domain Configuration of the Provisioning domain.

In the General tab, check Enable Persona Handling if it’s not already checked.

Save the update and then re-start the IdS-J service, Apache Tomcat, and DirX Identity Manager so that enabling persona management takes effect.

The persona’s email address can be different from the user’s email address.

The user’s main identity serves as a template for the persona. It inherits the attributes employeeType, employeeNumber and company. In the create persona dialog of Web Center, these attributes must be initialized with the values of the main identity and be read-only.

The persona’s common name is built according the rule:

cn=sn givenName employeeNumer P

for example, Smith John EN-7716 P.

Starting with the user’s second persona, a counter is appended to the common name; for example, Smith John EN-7716 P1 for John Smith’s second persona.

In DirX Identity Manager → Provisioning → Domain Configuration view, select the domain object; for example, My-Company.

Click Edit at the domain object.

In the General tab, check Enable Functional User Handling.

Save the update and then re-start the IdS-J service, Apache Tomcat, and DirX Identity Manager so that enabling functional user management takes effect.

The common name (cn) of the department-specific trainees must be Trainee for department.

The trainees' sponsors are the department managers. They create the trainees' functional users.

The new trainees must be located in the same folder as their sponsor, in the department folder.

Log in to Web Center as Taspatch Nik.

Search user Berner Hans from the Human Resources department. He is the manager of this department.

Select Berner Hans. His overview page is displayed.

Select the Functional Users tab to verify that he does not already have a functional user assigned.

Select the Create new functional user operation from the Users menu. The workflow selection page appears.

Select the workflow Create a trainee for the department.The Enter Attributes page appears.The values for Name, First Name and Last Name are initialized with default values as expected from the edits in the TraineeFromUser.xml object description.

Click Save. The Request Privileges page appears.

Click on Groups and assign the group dxr Mailbox Users of the Windows Domain Europe target system.

Click Save.

In DirX Identity Manager → Provisioning → Domain Configuration view, select the My-Company domain object.

Click Edit.

In the Compliance tab, check Risk Check active if it isn’t already checked.

Click Save.

Log in to DirX Identity Manager’s Connectivity view group, and then select the Expert View.

Navigate to Connectivity Configuration Data → Configuration → DirX Identity Servers → Java Servers → My-Company → My-Company-S1-servername and click on the last entry.

In the Resource Families tab, click Edit. Now move RiskGovernance from the Available table to the Selected table. Click Save.

Navigate to Policies → Risk Policies → Risk Policy.

In the General tab, check Is active (if it’s not already activated).

The Risk Limits fields in the General tab define values used for risk classification into low, medium, and high risk levels. We’ll use these values in this exercise, so leave them as they are.

The Risk Factors section in the General tab allows you to define up to nine different risk factors and their corresponding risk weights. We’ll use the risk factors and weights supplied with this risk policy, so leave this section as it is.

In Connectivity, select the Expert View.

Navigate to Connectivity Configuration Data → Workflows → Default → Identity Store, copy the entry RiskGvnContoller to Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store by pressing and holding down the Strg-key and the left mouse button and then moving the cursor with this workflow to the new location.

Click on the new entry Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store → RiskGvnContoller.

In the General tab, check Is Active.

In Provisioning → Target Systems, click Intranet Portal and then click the Advanced tab. At the bottom of the page, you’ll see the Risk Parameters with the Target system risk weight set to 2.

Navigate to Intranet Portal → Accounts and Groups → General → Manager Portal and click the Operational tab. At the bottom of the page, you’ll see the Risk Parameters with the Group risk weight set to 3.

Look at the risk weights of the other target systems and their groups. We’ll leave these values as they are.

In Provisioning, select Users → My-Company → Global IT → and click Pitton Lavina to select it.

Click the Risk Parameters tab to open it. You can see that all fields in this tab are empty.

Look at the Risk Parameters tabs of other users. All the fields in each tab are empty.

Log in to DirX Identity’s Connectivity view group and then select the Expert View.

Navigate to Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store → RiskGvnContoller. Right-click this entry and then select Run Workflow.

In Provisioning, select Users → My-Company → Global IT → and click Pitton Lavina to select it.

Click the Risk Parameters tab to open it. You can see that the fields are now populated and the Risk Level is set according to the Compound score, which is calculated from the Risk Factors and the defined limits in the risk policy.

Look at the risk parameters of other users, especially Taspatch Nik and Wagner Retha. All the fields in their Risk Parameters tabs are now filled.

Open Self Service → Display summary. You see the risk displayed as a circle filled in red. If you move the mouse over the circle, you can see the tool tip High.

Now choose Users → Select user and then click Search.

Step through the different result pages. You will find that most of the users have a low risk value (indicated with a circle outlined in green) and Wagner Retha at the last page with a medium risk level (indicated with a yellow half-circle).

Log out of Web Center and return to the DirX Identity Manager.

In Provisioning → Target Systems, click DirXmetaRole.

In the Advanced tab, change Target system risk weight from 8 to 1.

Navigate to Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store → RiskGvnController.

Right-click the RiskGvnController entry and then select Run Workflow.

In Provisioning, select Users → My-Company → Global IT → and then click Taspatch Nik to select it.

Click the Risk Parameters tab to open it. You can see that his Risk Level has changed to Low.

Look at the risk parameters of the other users, especially Pitton Lavina and Wagner Retha. All Risk Levels are now set to Low.

Open Self Service → Display summary. You see the risk displayed as Low.

Now choose Users → Select user and then click Search.

Step through the different result pages. You will find that mostly all of the users have a low risk value.

Log out from the Web Center and return to the DirX Identity Manager.

In Provisioning, select Target Systems and then click on DirXmetarole to select it.

In the Advanced tab, change Target system risk weight from 1 to 8.

In Provisioning, select Policies → Risk Policies → Risk Policy.

Change the Upper Risk limit from 3.5 to 1.5 and change the Lower Risk limit from 1.5 to 0.

In the Connectivity view group, select the Expert View.

Navigate to Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store.

Right-click RiskGvnController and then select Run Workflow.

Choose Users → Select user and then click Search.

Step through the different result pages. You will now find a lot of users with medium risk level (for example, Pitton Lavina) and some of the users with high risk level (for example,. Wagner Retha).

Log out from Web Center and return to DirX Identity Manager.

In the Provisioning view, navigate to Policies → Risk Policies → Risk Policy.

Change the Upper Risk limit from 1.5 back to 3.5 and the Lower Risk limit from 0 back to 1.5.

In Connectivity → Expert view, navigate to Connectivity Configuration Data → Workflows → My-Company → Main → Identity Store.

Right-click RiskGvnController and then select Run Workflow.

In DirX Identity Manager’s Connectivity view group, select the Expert View.

Navigate to Connectivity Configuration Data → Schedules → My-Company.

Right click on the My-Company entry and then select New → Schedule.