Manual Provisioning of Offline Systems

This chapter describes the use case where various connected systems in the customer environment are to be connected via manual provisioning.

Detailed Definition

This use case assumes that there are connected systems that are not yet automatically managed from DirX Identity. Typical reasons are:

  • The number of users (accounts) in the connected system is low or the change frequency in that system is too low. The effort to connect this system with automatic provisioning is too high.

  • The customer wants to integrate the system as fast as possible into the identity management solution. This establishes a common view on all systems and adds noticeable value in the compliance area (all actions are tracked via auditing). In a later stage of the project the system could be integrated more tightly with automated provisioning.

This use case assumes that the connected system is modeled as target system of type RequestWorkflow in DirX Identity. If the system already exists, an initial load process is necessary to fill the target system with accounts, groups and memberships.

The system is treated as any other target system in DirX Identity, for example the accounts have to be associated with users, the groups have to be integrated into the privilege model or can of course be used for direct group assignment.

From now on this target system can be used as any other one. All actions that occur as there are for example account or group creations or modifications or management of group memberships create approval workflows where the administrators of the connected system are the approvers (let’s better say workers).

The administrators work on their tasklist, see the task requests (for example an account add request with all attributes) and perform each required task on the connected system side. After they have done it successfully (for example they added the account), they approve the task and this sets the relevant states in the corresponding object in the target system. All actions are audited given that the audit policies are set correctly.

Evaluation of this Use Case

This section elaborates on advantages and disadvantages of this solution.

Advantages

  • Fast integration into the identity management solution.

  • Low effort for integration.

  • Only slight changes to administrative tasks (going away from paper to request workflow tasks).

  • Ability to audit all actions regarding this target system.

Disadvantages

  • No automatic checks possible whether the actions were correctly performed by the relevant administrator.

  • No way to validate additional manual actions in the connected system.

Additional Documentation

Besides the information in this document you can find additional documentation in the DirX Identity documentation:

  • Read the follow-on tutorial "Using Manual Provisioning" in the DirX Identity Tutorial. Perform the example use case in the sample domain to understand the feature.

  • Read the description of the relevant workflows in the DirX Identity Application Development Guide. Read about the "Service Management Workflows" in the chapter "Understanding the Target System Workflows" and the "Manual Provisioning Workflow" in the chapter "Using Request Workflows".

Set Up and Configuration

You have to set up

  • The target system that represents the offline system.

  • Set up the initial state of the target system to reflect the state of the offline system (manual initial load).

  • Configure a corresponding Manual Provisioning workflow in the Provisioning view

  • Configure the Service Management workflows in the Connectivity view

All parts must fit together to work correctly.

Setting up the Target System

For each offline target system create a corresponding target system:

  • In the Provisioning view group open the target system wizard.

  • Select Service Management (type = RequestWorkflow) as template.

  • Enter a name and a description for the offline system.

  • Set a cluster and domain name that is used by the corresponding Java-based workflows for reference. If you have a set of offline systems use as cluster the set name (for example MyOfflineSystems) and as domain the name of the offline system.

  • Set the host and port address of the Java-based server where the request workflow engine runs.

  • Click through the rest of the pages and then click Finish.

A new target system is created.

Initial Load of the Target System

If your offline system already exists (which is probable), you need to load the existing information (accounts, groups and memberships) into the newly created DirX Identity target system. Use one of these methods:

  • Enter the information manually. Create all accounts and groups and then add the accounts as members to the relevant groups. This is of course only possible for a small amount of data.

  • Export the data from your offline system into any of the formats DirX Identity can read (LDIF, CSV, XML). Set up and configure a workflow that imports this information into the target system.
    Note: we recommend building a validation workflow to initially load this data. The advantage is that you can run the workflow again from time to time to validate whether the administrators work correctly.

Configuring the Workflows in the Provisioning View

Set up the necessary request workflow templates for manual provisioning:

  • In the Provisioning → Request Workflows view create a workflow folder for all request workflows that you need for manual provisioning (for example Provisioning).

  • Copy the workflow template Service Management → Manual Provisioning from the Default tree.

  • Rename the copied workflow to reflect its use. Name it according to the target system where it is used.

  • Adapt the workflow configuration as required.

Configuring the Workflows in the Connectivity View

During target system creation, the corresponding workflow was already created. It is located in the folder named Service Management. Perform these steps to configure the workflow:

  • Rename the workflow folder and the workflow according to the created target system. Best is to use the name of the offline system.

  • Open the workflow wizard and

  • General info: Set the active flag and set a timeout for the workflow.

  • Join Activity General Info:

    • Either keep the resource family Request_Workflow or define your private one.

    • Set the error handling timing parameters.

  • Join Activity Controller Parameters:

    • Set the Write Audit Log flag to enable status entry generation.

  • Request Workflow Settings:

    • Set the Primary and Secondary Workflow DNs.

    • Adapt the Account Mapping to CS, Group Mapping to CS and Membership Mapping to CS steps. These are the attributes that are presented to the administrators in Web Center.

  • Adapt and extend the mapping as required.

  • Set up the resource family Request_Workflow (or the one you defined above) at your Java-based Server configuration object.

  • Restart the Java-based Server.

Running the Use Case

To run the use case you need to create and change objects (groups and accounts) in your target system:

  • Create a group. The creation request starts a Java-based workflow that itself starts a corresponding request workflow.

  • Check the corresponding workflow entry in the Connectivity → Monitor view. It contains information about the objects to create or to change.

  • Check the relevant request workflow entry in the Provisioning → Request Workflows → Monitor view.

  • Assign the group manually to a user that does not yet have an account. View the new workflow entry in the Connectivity → Monitor view. Check also the corresponding request workflow entry in the Provisioning → Request Workflows → Monitor view.

Alternative or Extended Configurations

The default workflows coming with DirX Identity show only one possible use case. Here are some examples of possible modifications.

Building Separate Request Workflows

The default sample workflow handles additions, modifications and deletions. If you have specialized administrators, you could build three different workflows that each handles only additions or modifications or deletions. Set in this case the When applicable section only for one operation.

Of course you can use other criteria to separate the workflows. For example you could distribute the work to the administrators based on the accounts organizational unit or locality attribute (use the Condition section in the When applicable area). Prerequisite is that you inherit the attribute from the user to the account.

Using Different Workflows for Accounts and Groups

You can use different workflows for accounts and groups. Set the relevant parameters in the real-time workflow wizard’s Request Workflow Settings step.

  • Set the Primary Workflow DN field to the workflow that shall be used for accounts. Note that this workflow also handles memberships because these are configured at the account side.

  • Set the Secondary Workflow DN field to the workflow that shall be used for groups.