Configuring the Required Provisioning Entities

The Identity Provisioning service ensures the synchronization of the entities between a source system and one or multiple target systems.

• Source – а system, where the company is currently managing the corporate identities.
• Target – а system that needs to be populated with corporate users and other entities.

You can configure the required provisioning entities in order to ensure proper synchronization between source and target systems. You can also use proxy systems for indirect connections between a system supported by Identity Provisioning and an external application that uses a SCIM 2.0 API to consume identities from the proxy system. For example, you can use SAP Identity Management as an external consuming application.

Properties help you to customize the way your identities are read from a source system or provisioned to the target one. They can also filter which entities and attributes to be read or skipped during the provisioning job.

For every system supported by the Identity Provisioning service, there is an initial (default) transformation logic that converts the system-specific JSON representation of the entities from/to one common JSON. You can keep the default transformation or modify the mapping rules to reflect the current setup of entities from your source or target system.

This section defines the three types of systems you can use for provisioning identities: source, target, and proxy.

A target system is the connector used for writing (provisioning) entities. Target systems are usually clouds, where Identity Provisioning creates or updates the entities taken from the source system.

A target system can be connected to a single or multiple source systems.

A proxy system is a special connector used for "hybrid" scenarios. It exposes any Identity Provisioning supported backend system as a SCIM 2.0 service provider, which can be consumed by any SCIM 2.0 compatible client application, without making a direct connection between them.

To achieve this, the Identity Provisioning service uses this special proxy system to execute provisioning operations (create, update, delete, and so on) requested by the client application.

The examples in this section cover using of SAP Identity Management as a consuming client application but you can use any other SCIM-based identity management solution.

To provide communication between SAP Identity Management and the backend system, the proxy application uses a SCIM 2.0 protocol. A system can act as a proxy if it supports both read and write operations.

Proxy System - How It Works

1. The Identity Provisioning service exposes the backend of a supported system as a "proxy".
2. An external application (for example, SAP Identity Management) regards the proxy system as its backend system.
3. The entities (users) exposed by the backend system are mapped to SCIM 2.0 entities, if possible. If not possible, the SCIM standard provides a mechanism to define a new resource type with the appropriate schema. You can use the custom resource type to map the backend entities.
4. Finally, the external application can start sending REST web service requests to the proxy system in order to read identities from the backend of the SCIM 2.0 system.

All provisioning systems (source, target, and proxy) that you configure in the Identity Provisioning administration console are displayed under the Customer Managed category.

The system types have similar Identity Provisioning user interface. The details in the following table provide you with what you need to set up a source, target, or proxy system:

You need to set mandatory properties to configure the connection between your source and target systems.

For your system provisioning goals, you can set properties in two places:

• SAP BTP cockpit: Destinations
• Identity Provisioning UI: Properties

If the same properties exist in both the Destinations editor (in the cockpit) and in the Properties tab (in the Identity Provisioning UI), the values set in the Properties tab are taken with higher priority.

Properties help you to customize the way your identities are read from a source system or provisioned to the target one. They can also filter which entities and attributes are going to be read or skipped during the provisioning job. According to their usability, properties can be categorized in the following way:

• Standard
• Credential
• Default
• Parameterized
• Internal

Properties can help you filter which entities and entity attributes are read from the source system or written to the target system. According to their usability, properties can be categorized as follows:

Each source, target, and proxy system support specific types of properties - for example:

The values of these properties contain sensitive information that must not be displayed as plain text. The default credential property name is Password, which can represent standard passwords, private keys, or OAuth client secrets. When you add a credential property, its value is displayed as an encrypted string. For better security, the encrypted string is always displayed as 40 characters, irrespective of the length of your password.

These properties depend on the particular connector type. They exist in the transformations by default. It is possible to delete some of them, but this may cause a loss of provisioned data – for example:

They use parameters taken from the system property sets. The parameters consist of a unique key and a value. Like the standard properties, they can be configured in the system's Properties tab, and/or in the system's destination properties (in the platform cockpit). When one parameter exists in both property sets, the system properties have priority over the system destination properties.

In the JSON data, the unique key of one of these parameters is surrounded by the percent symbol (%). During the transformation evaluation, each occurrence of %<...>% is replaced by the corresponding parameter's value. Parameter references without a value are left unchanged – for example:

123456789101112131415161718

/* LDAP Server (source) system: */

{
 "sourcePath": "$.%ldap.attribute.user.mail%[0]",
 "targetPath": "$.emails[0].value",
 "optional": true
 },



 {
 "sourcePath": "$.%ldap.attribute.user.givenName%[0]",
 "targetPath": "$.name.givenName",
 "optional": true
 },

An example of this is shown in the following table: