IGA Capability: Fulfillment
Alternative names
-
Provisioning/deprovisioning
-
Change propagation
Fulfillment Functions
-
Identity resource management. Maintenance of connection parameters and connector code for interaction with source/target systems. Inventory of identity resources and connectors, maintenance of state and schema. Identity schema discovery.
-
Communication with remote systems. Execution of create/read/update/delete (CRUD) operations in remote systems (identity resources). Implementation of communication protocols, adaptation of protocol differences, data type conversion. Execution of additional operations (e.g. provisioning scripts). Simulation of capabilities that remote systems do not support.
-
Handling of fulfilment failures. Detection, interpretation and handling of communication and configuration errors, communication security violations and similar failures. Managing operation retries, delayed operations and similar corner cases.
-
Identity state tracking. Tracking identity attributes, e.g. caching the attributes in the database of IGA system. Tracking of identity status, including identities that do not exist in identity resources (e.g. accounts that were not created yet or deleted recently).
-
Management of manual fulfillment operations. Managing the process of manual fulfillment, initiating manual operations, tracking operation state, communication with ITSM systems. Handling operation feedback (e.g. in case of semi-manual fulfillment).
Overview
Simply speaking, fulfilment is a capability that deals with propagation of changes to target systems. Fulfilment creates, modifies and deletes user accounts. Strictly speaking, this capability fulfils the policy, e.g. by creating an account when such an account is mandated by the policy. However, fulfilment often needs to read and compare the data in addition to create, modify and delete operations. This creates a significant overlap with other capabilities, namely entitlement management and synchronization. Moreover, attribute schema management, interpretation and transformation of attribute values and other functions are required for almost every IGA capability as well as they are required for fulfilment. Therefore we will be using the term fulfilment to mean all the necessary low-level functions that deal with target and source systems, we will not limit the fulfilment to mere propagation of changes.
The desired implementation of fulfilment is almost always automatic fulfilment. In that case the changes are made to target system automatically, by a connector on an agent that executes the commands of an IGA system. This is quite obviously the most convenient and reliable method. However, development and maintenance of a connector or an agent may be quite demanding. Some target systems may not even provide required capabilities in a form of re-usable programming interface (API). Therefore, the deployments sometimes opt for manual fulfilment. In that case the change is executed by a human operator, driven by a request from an IGA system. IT service management (ITSM) systems are often used to deliver instructions to the operator, and to track the progress of the task. While the manual fulfilment is usually practical and very cost-efficient solution, it has major drawbacks. As an IGA system cannot reach the target system, it cannot make sure that the account was created correctly, or even more importantly, that the privileges were correctly removed or account deleted. This creates a serious security issue. Therefore, some IGA systems provide an option for semi-manual fulfilment. In that case the operations are executed by a human operator. However, there is process to periodically export the data from the target system and deliver them to IGA platform for inspection. IGA platform identifies any inconsistencies, and creates tasks for operators to remedy the situation.
Automatic fulfilment is usually implemented using identity connectors. Connectors are relatively small bundles of code, implementing the details of network communication with the target system. Connectors are using standardized network protocols or interfaces (APIs) to communicate with target system, whenever such protocols or interfaces are available. Some IGA platforms are using agents instead of connectors. Agents are installed into the environment of the target system, communicating with the target system locally. Agents are usually more powerful than connectors, however, they usually create a significant maintenance burden.
Connectors are relatively simple pieces of code, designed to use particular protocol or interface. However, connector does not know the host where it is supposed to connect, does not know the credentials or other connection details. Such details are specified in identity resources, data structures describing communication channel to identity databases. Identity resource usually represent an application with its internal user database. However, identity resource may represent a connection to a directory service or identity provider used by many applications.
Identity resource usually deals with identity schema. The schema is a description of data structures used by a particular identity resource. For example, the schema usually specifies names and types of attributes that user account may have. Some applications have static schema, which is the same for all application instances. However, there are systems that flexible or extensible schema, such as relational databases and LDAP directory servers. In such cases, identity resource often supports schema discovery, determining the schema dynamically at run-time.
Apart from connector management, the fulfilment capability includes significant amount of error handling functionality. Protocols and interfaces provided by target systems significantly vary as to their capabilities. E.g. some systems can disable accounts, other cannot. Some systems can delete an account, other can only permanently disable it. Some of these details can be addressed in the connector code. However, many details and edge cases have to be addressed by the fulfilment components. For example, the fulfilment usually need to simulate capabilities that the target systems do not have, such as simulation of account disable by disabling/changing the credentials. Error handling is an important part of the functionality, e.g. making sure that an operation is re-tried in case of network failures. Error handling code is often very complex, as there are numerous interactions with other capabilities, especially synchronization, entitlement management and the policies.
Fulfilment components usually provide additional functionalities, such as ability to execute scripts on target systems. Such functionality is often used to complete account provisioning, or it is used to archive filesystem data in case of account archival.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability: