Overview

In a typical customer environment for an identity management solution you have to connect standard connected systems like Active Directory or IBM Notes. DirX Identity comes with a comprehensive set of pre-defined target system types and the corresponding provisioning workflows.

In many cases there are other legacy systems or connected system types in place that shall be connected to DirX Identity where the standard connectivity of DirX Identity does not provide a solution. This document explains what needs to be done to connect such systems.

The generic procedure to implement a viable solution is:

  • Evaluate the system to connect thoroughly (see the section "Evaluation of the System to Connect" below).

  • Define a target system instance or template (described as the first two use cases)

  • Implement a connector to access the target system or use an alternative access method. How to implement a connector is not part of this document. Read the DirX Identity Integration Framework Guide for more information.

  • Configure the necessary provisioning workflows (described as the third use case)

DirX Identity supports this process completely. Correctly defined objects in provisioning and connectivity configuration allow seamless integration of new connected systems into DirX Identity.

Use Cases

This document describes three use cases in detail. Be aware that other use cases are possible that are not described in this document.

Defining a Custom Target System Instance

This use case allows you to create a new target system instance through customization of a generic built-in target system template. According to the properties and the API of the connected system you have to set up a target system instance together with the necessary connected directory and the provisioning workflows.

This method is applicable if you need only one instance of the new custom target system.

Defining a Custom Target System Template

This use case is a natural extension of the previous one. After definition of a new target system template you can create a set of target system instances.

Typically you will use this case when modeling a more common target system type that is not supported by DirX Identity but shall exist in multiple instances within the company.

Creating Java-based Provisioning Workflows

This use case explains how to build the necessary Java-based provisioning workflows for a custom target system type or one of its instances.

Use Case Comparison

The following table compares the first two use cases described in this document to help you with your decision process. The third use case is independent from the other two and necessary in any case.

Table 1. Use Case Comparison
Criteria Custom TS Instance Custom TS Type

Number of instances required

1

N

Customization depth

Low

High

Re-use necessary

No

Yes

The table presents the following evaluation criteria:

Number of instances required - the number of target system instances the customer needs.

Customization depth - the number of necessary customization regarding one of the existing target system templates. High customization occurs if there are many custom JavaScripts and reports necessary.

Re-use necessary - in hosting environments it might be necessary to copy the target system templates to various domains.

Evaluation of the System to Connect

Before you start any implementation, evaluate the following questions and determine the requirements that are necessary to implement connectivity to the system you want to connect to.

Additionally, answering these questions can help to choose an existing target system type as a starting point for your custom target system instance or type.

Representation of Identities

It is important to understand how the system represents identities which means users.

How Does the System Represent Identities?

There are various ways how identities can be represented:

  • Most systems use so called accounts to represent the identity of the specific user.

  • Some systems have several types of identities, for example a user entry that represents the basic identity and a set of related entries that are related to this basic identity and keep more specific information.

In the first case it is quite easy to connect to DirX Identity because an account on the target system side represents exactly one account on the connected system side.

In the second case you have to map an account on the target system side to an account structure on the connected system side. This requires setting up multiple channels in the Java-based workflows to handle this situation correctly.

How Many Accounts Exist and What is the Typical Change Frequency?

These two numbers help to decide for the appropriate provisioning method:

  • If there are only a few hundred accounts or a larger number but the change frequency is low, you could think about using manual provisioning (for more information see the chapter "Manual Provisioning of Offline Systems" in the DirX Identity Use Case Document Service Management).

  • If there are thousands of accounts and a medium or high change frequency it makes sense to think about automatic provisioning via a connector.

The automatic provisioning method requires much more effort because you need to implement a connector and a set of provisioning workflows.

Can Accounts be Disabled?

This aspect is mainly relevant for the connectivity configuration. It influences the handling of the dxrTSState attribute within the connectivity workflows.

How does the system model access control?

In this section you have to evaluate the access control model in various dimensions.

Access control model

There are several methods how access control can be implemented:

  • Some systems implement access rights to resources as attributes at the account entries. This method is called DAC (discretionary access control). Main disadvantage is that general changes in the access control model requires individual adaption of the access rights for a set of accounts.

  • To avoid this problem, many systems offer a group based approach. In these systems groups can be defined that have specific access rights to resources. Assigning an account to one or more of these groups inherits the corresponding access rights to the accounts. Changing the access rights of such a group changes the access rights of the assigned accounts automatically.

  • A third category of systems allows modeling a hierarchical model of groups. In this case the higher level groups are called roles (this method is called RBAC = role based access control). They aggregate some lower level roles or groups. Assigning one or more of these roles to a user inherits all lower level access rights to this user.

Dependent on the found model it is not straight forward to find an appropriate model in DirX Identity. We recommend the following methods:

  • If there are only accounts with access control attributes, create for each access control attribute a corresponding group in the target system. Assigning the group manages the corresponding attributes at the account via DirX Identity’s obligation mechanism.

  • If there are accounts and a simple group model you can use the natural DirX Identity model with accounts and group (a one to one relationship).

  • If the system uses groups and roles you should decide for one of the levels. Your decision should be driven by the granularity you want to control and make visible in DirX Identity. In any case you will model either the groups or the roles as groups in the target system.

Note that in case that the system has only accounts, the account management of such systems in DirX Identity can be modeled via the assignment and unassignment of a default dummy group which will be not synchronized to the connected system at all. An example of such an approach may be found in the Imprivata OneSign target system definition and its corresponding connectivity workflows.

Does the System Allow For Nested Groups?

Check whether a group in the system to connect to can contain another group as a member (so called nested groups)? DirX Identity supports nested groups in a limited manner. Try to get rid of the nested groups if possible, that means restructure the system accordingly.

Structural Conditions

The way how objects are organized and structured in the target system can influence the complexity of your provisioning approach.

Are Groups and Accounts Stored in a Hierarchical or Flat structure?

There are systems that keep all accounts and groups in a flat structure, others use object hierarchies to order and structure the objects.

A hierarchical structure is common for LDAP-based systems and also for Active Directory.

Databases keep the accounts and groups in separate tables which is a flat structure.

Are Memberships Stored at Accounts or at Groups?

These types can exist:

  • In most cases the memberships are stored at the group side. A big disadvantage of this method is that all these systems have either an upper limit (for example RACF allows only 5000 memberships per group) or performance decreases drastically for high numbers of memberships. Unfortunately the maximum number of memberships can be equal to the number of identities if all users shall be member of a specific group. Examples for such systems are LDAP and Active Directory.

  • Much better is the approach to store the memberships at the account side because even if you have a large number of groups in your system, no account will have more than some thousand memberships. Due to that fact high member numbers do not occur. An example for such a system is SAP UM R3.

  • Some systems use both methods together. For example the UNIX-PAM target system type stores memberships at the group object but the primary group must be directly stored at the account object.

  • Special types of systems are the ones that are based on relational databases. They store the membership in a special table which requires an advanced connectivity configuration for Java-based workflows.

In a DirX Identity target system you can configure both methods. Switching the flag triggers an automatic reconfiguration of the target system that can last a long time if a lot of accounts and groups is to change.

Additionally the provisioning workflows can handle cross memberships, that means the target system keeps the memberships on the account side and the connected system keeps it on the group side (the group side versus account side scenario is possible but does not make any sense because in this case the account side / account side scenario should be used).

We recommend strongly using account side memberships on the target system side whenever possible.

Which provisioning interfaces are available?

There are many methods possible:

  • An optimal solution is if the system provides an SPML compatible web service interface. In this case the standard SPML connector of DirX Identity can be used.

  • Many systems have their own proprietary provisioning API or an API that can be used for provisioning. In this case you have to implement a custom connector that provisions via this API. Alternatively you can use the manual provisioning method (for more information see the chapter "Manual Provisioning of Offline Systems" in the DirX Identity Use Case Document Service Management).

  • If a system provides only a file-based interface, you can implement a custom connector that implements this interface or use the manual provisioning method (for more information see the chapter "Manual Provisioning of Offline Systems" in the DirX Identity Use Case Document Service Management).

  • If a system does not provide any suitable interface you have two options:
    Use the Boston Workstation and the available target system and derive a variant of this connectivity package or use the manual provisioning method (for more information see the chapter "Manual Provisioning of Offline Systems" in the DirX Identity Use Case Document Service Management).

    because the Boston Workstation interface has proven to be unreliable, we recommend to perform manual provisioning.