Configuring Custom Scenarios

Creating a customized DirX Identity scenario both in the Provisioning and Connectivity configuration and maintaining its objects can be a complex task.DirX Identity provides easy-to-use, comprehensive tools to simplify this task.You can use the Identity Manager Provisioning and Connectivity views to create identity creation, maintenance, and provisioning workflows that are consistent with the target system structure in your Provisioning domain.

To create and configure a custom DirX Identity scenario for a DirX Identity domain, perform the following steps with Identity Manager:

Use the target system creation wizard in Provisioning → Target Systems to create a new target system in your new Provisioning domain.The wizard automatically creates a new scenario in the Connectivity domain provided no other scenarios yet exist and places the necessary configuration objects (connected directories and workflows) into this scenario.
Use the Provisioning view to refine the configuration of the newly created target system and its objects.
Use the Connectivity view to refine the configuration of the newly created maintenance and target system workflows.
Create and maintain additionally the necessary identity creation workflows (source workflows).

For additional target systems, perform these steps:

Use the target system wizard to create additional target systems. The necessary configuration objects (connected directories and workflows) are added to your existing scenario in the Connectivity view automatically.
Use the Provisioning view to refine the configuration of the newly created target system and its objects.
Use the Connectivity view to refine the configuration of the newly created maintenance and target system workflows.

To create clustered target systems, see the section "Creating Cluster Target Systems".

Creating the New Scenario

You can use the target system creation wizard to create a new target system and a new custom Connectivity scenario for your Provisioning domain. To run the target system creation wizard in this way, you need to have:

A fully configured Provisioning customer domain that contains only the default target system DirXmetaRole.
An installed Connectivity configuration.

To create the first target system and set up the new Connectivity scenario automatically:

Log in to DirX Identity Manager and select Provisioning.
Click the Domain Configuration view.
Click the top-level object (it has the name of your Provisioning domain).
Check the Connectivity configuration parameter in the General tab. If it is not correct, change it to the server where your Connectivity configuration domain is installed.
Click the Target Systems view.
Optionally you can create a folder or several folders that reflect your target system environment.
Click either on the top level object Target Systems or on one of the created folders, and then select New → Target System. The Target System Wizard opens. Click Next.
Select one of the available target system templates. Click Next.
Set the name of the new target system. Click Next.
Set the target system advanced parameters. Click Next.
Set the target system options. These might differ according to the target system template. Click Next.

At this point, we have defined the parameters for the target system object in the Provisioning domain. Now the target system creation wizard detects that a scenario does not yet exist and prompts for the parameters that describe how to create the scenario:

The wizard will automatically create a new scenario with the same name as your Provisioning domain and will create a new identity store representation in your new scenario.
Next, the wizard prompts for the Maintenance Workflows to copy to the new scenario. Click Next. The wizard copies the workflows (this action takes some time to complete).
Now the wizard prompts for the Connected Directory template to be used for the new target system. Use either the proposed templates (Show preferred) or choose any of the other available templates (Show all). The latter choice makes sense, for example, if you intend to create an eDirectory target system. In this case, the Provisioning view assumes an LDAP type, whereas the Connectivity connected directory should be of type NDS (so choose the NDS template). Click Next.
You can synchronize the schema and change the attribute configuration of the new connected directory (only for target systems where this makes sense) in the next two steps. Click Next.
The wizard’s Configuration step (and depending on the target system, an additional next step) lets you define the most important parameters:
Account Base and Group Base of the target system have already been defined and cannot be changed.
Set the Service and the Bind Profile parameters to the values of your target system connected directory.
Set the Connected Directory parameters. These parameters may differ depending on the connected directory type.
Click Next.
Now the target system wizard asks for the Provisioning Workflows to create. Select from Synchronization, Validation and Password Synchronization.
If you select Password Synchronization, you need to fill in the next four steps. For the other selections, the target system wizard copies and configures the workflows.

When the wizard finishes, you should have a completely configured Connectivity scenario with all of the necessary elements. The configured workflows should run. Of course, you might need to change some details, like the mapping of additional account and group attributes. The next section describes how to make these changes.

Refining the Scenario

You can use the Provisioning → Target Systems view to maintain your newly created scenario. Click any of the target systems in the Target Systems view and select Connectivity. The subsequent menu selections allow you to:

Change the configuration of the connected directory (Configure Connected Directory).
View the connected directory (if the Viewer command is entered correctly) (Open Connected Directory).
Copy new workflows to the workflow line between Identity Store and the connected directory (New Workflow).
Assign an existing workflow to the workflow line between Identity Store and the connected directory (Assign Workflow).
Configure, run, report or remove the validation workflow (Validation).
Configure, run, report or remove the synchronization workflow (Synchronization).
Configure, run, report or remove any of the other assigned workflows (Workflows).

You can also manage the Identity Store connected directory from here. Right-click the Target Systems root node and select Connectivity. The subsequent menu selections allow you to:

Change the configuration of Identity Store (Configure Connected Directory).
View the connected directory (if the Viewer command is entered correctly) (Open Connected Directory).
Copy new workflows to the workflow line between Identity Store and the connected directory (New Workflow).
Assign an existing workflow to the workflow line between Identity Store and the connected directory (Assign Workflow).
Configure, run, report or remove one of the assigned workflows (Workflows).

As you can see, the most important features of the Connectivity view are also available in the Provisioning view.

Scheduling and Combining Workflows

You should set up schedules that define when your created workflows shall run. The methods you use to set up schedules for DirX Identity Connectivity scenarios are highly dependent on your environment. We recommend that you:

Run synchronization workflows periodically, for example, every half hour. Optionally you can use a nested workflow that performs account-to-user joining after each run.
Run policy execution workflows and privilege execution after each creation workflow or after a sequence of creation workflows (use nested workflows and run them once a day or more often).
Run validation workflows each night or during each weekend (depending on the number of accounts and groups in your target systems). We recommend that you use a nested workflow that performs account-to-user joining after each run.
Run check consistency workflows every night or during each weekend.

Creating the Identity Creation Workflows

The target system creation wizard helps you to create the initial Connectivity scenario and copies and configures everything that is necessary to handle the provisioning of the target systems. However, the wizard does not handle identity creation workflows. You must use the Connectivity view to create and maintain these workflows. For information about these tasks, see the Importing Identities section in the "Getting Started" chapter of the DirX Identity Tutorial.

Creating Cluster Target Systems

Creating clustered target systems is a bit different from creating a single target system. Read the section "Cluster Workflows" in the DirX Identity Connectivity Administration Guide to understand the concept of cluster workflows. The chapter "Java-based Workflow Architecture" in this guide provides additional information.

Before we start with the creation procedure, be aware that the structure for cluster target systems is fixed:

Target Systems → cluster_container → cluster → target_system

Here is an example that shows how you can use this structure:

Target Systems
    UNIX-Clusters
    Linux-Cluster
        Linux1
        Linux2
        ...
        Linux<n>
    Windows-Clusters
    Europe-Cluster
        ADS-EU1
        ADS-EU2
        ...
    US-Cluster
        ADS-US1
        ADS-US2
        ...
Other-Clusters +
    ...

The UNIX-Clusters folder comprises a Linux-Cluster with the target systems Linux1 to Linuxn. The configuration of each cluster is identical except for some specific parameters like server addresses and bind profiles. The Windows clusters in this example are structured according to areas.

To set up clustered target systems, perform these steps:

Select the Target Systems view and then click the top node. Select New Cluster Container from the context menu and create a cluster container. In our example above, these are the UNIX-Clusters and Windows-Clusters objects.
Click the created object and then select New Cluster from the context menu. Define a name for your cluster. In our example, this would be for the UNIX-Clusters cluster container the object Linux-Cluster.

You can create as many new target systems for your cluster below these clusters as you need. DirX Identity provides Web services for target system creation that are designed to set up cluster target systems efficiently, because this task requires setting many parameters for each system. Alternatively, you can create these target systems by hand, as follows:

Use the target system wizard to create a first target system below the cluster folder. Select the workflows that are necessary for provisioning. Select the cluster workflows - if present - for your target system template, or select non-cluster workflows. You can easily adjust them to work with cluster target systems.
After creating the first target system, move the Configuration folder one level up just below the cluster folder to allow its use by every subsequently created target system. Remember that all target systems in a cluster use the same set of object descriptions and other configuration definitions. Note that the Configuration folder will not be found if it is located anywhere else; that is, anywhere other than below the target system or - for a cluster - in the cluster folder that corresponds to the target systems that belong to the cluster.
If you were not able to select cluster workflows in the step above, change the copied workflows in the Expert view of the Connectivity view group:
Change the controller to the corresponding cluster controller type.
Adjust any other parameters that need to be adapted.

Now you can create additional cluster target systems:

Use the target system wizard again, but do not select additional workflows. Remember that you can use one provisioning workflow for all target systems in a cluster. Delete the Configuration folder beneath the target system created again by the target system wizard, because you’ll use the one you moved up one level after you created the first target system.
For every created target system, set these parameters:
Set the Connected Directory link on the General tab to the same connected directory as the first target system.
Create an account object, for example, named bindaccount, for the purpose of binding to the connected system beneath the Accounts or Accounts and Groups container. Account objects are not allowed to be created under a different container. Then move it up one level in the Data View to exclude it from synchronization to the connected system. The link to this bind account is set in the Bind Parameters section in the Server Connection tab of the target system. Set the password of this account in the Data View userPassword attribute. This action sets the dxmPassword accordingly. Using an existing account that is linked to a user can cause problems because the workflow may no longer be able to log in to the connected system if the password is changed. Therefore we recommend using a separate bind account where you manage the password manually. As this account may be used as access for password modifications, it must have sufficient access rights (preferably an administrator account) in the connected system.

The dxrName attribute of the bind account must contain the bind user name in the form domain*\*user name.
Set all other necessary parameters on the Workflow Configuration (for some target system types this tab is called Server Connection), Connector Configuration and Environment Properties tabs. These parameters are specific to the target system. Keep in mind that all target systems in the cluster use the same cluster workflows configured in the Connectivity view group.

If, for example, you want to specify some connection-specific properties like the following ones for the SapECCUMConnector:

<property name="client" value=800/>
<property name="accessToCUA" value="FALSE"/>

you must specify those properties as tag*=value pairs (client=800, accessToCUA=FALSE) in the Connector Configuration tab - or directly dxmSpecificAttributes in the Data View - of the Provisioning Target System object.

The tag=value pairs specified in the Connector Configuration or Server Connection tabs are stored in the LDAP attribute dxmSpecificAttributes and added to the <connection> section of the specific target system connector on workflow execution.

The tag=*value pairs specified in the Environment Properties tab are stored in the LDAP attribute dxrEnvironmentProperties. The environment properties must contain at least those attributes that are needed in a non-clustered workflow and specified in the Provisioning tab of the Connected Directory, like role_ts_account_base, role_ts_group_base or user_base. You can specify any property here and refer to it on the Connectivity workflow side - for example, in channel search base definitions like $\{env.user_base} - to restrict the search to a target system-specific user base, or you can refer to the environment properties in the mapping.

Note that some attributes like the base nodes for accounts and groups exist both in the Provisioning-side target system and the Connectivity-side connected directory. The Connectivity-side attributes, if specified, are overwritten by the target system attributes when the workflow runs for that specific target system.
If the target system type of the cluster is OpenICF, every target system contains an additional tab where bind parameters and server address/port and the bundle-specific parameters are stored for the OpenICF server. Like the target system itself, the OpenICF server bind profile requires an additional account object which is referenced here; to exclude it from any synchronization, we recommend placing this account object alongside the target systems in the cluster. If several OpenICF servers belong to the cluster, but the bind password is the same for all of them, one such account object is sufficient; otherwise several must be created. One additional restriction applies to target systems in an OpenICF cluster: while DirX Identity can process the address localhost, the OpenICF server does not recognize a "root", so using localhost” results in an error.
All the specific attributes in the Workflow Configuration, Connector Configuration, Environment Properties and OpenICF Server Configuration (for OpenICF) tabs are read from the default configuration on the Connectivity side and need only be present on the Provisioning side if the value differs for the target system. If no value is present in the target system, the default is evaluated. For OpenICF, where the server configuration is comprised of several bundle-specific attributes and the necessary bind profile attributes, this means:

1) If only one bundle is used (which we expect to be the main case), the bundle-specific attributes can be used from the workflow and need not be entered in every target system.

2) If the same password is used in all OpenICF servers in the cluster, the bind profile can be used from the connected directory and need not be entered in every target system, thus also making the additional bind account redundant.

3) If only one OpenICF server is used, the bind profile and the server address/port can be used from the connected directory/service and need not be entered in every target system, thus again making the additional bind account redundant.

4) For all other cases, remember that the values entered on the Connectivity side are used. They must only be entered in the actual target system if they differ.