Identifying Provisioning Services Operations

Objectives

After completing this lesson, you will be able to:
  • Add source, target, and proxy systems.
  • Connect to on-premise systems.
  • Manage full and delta read.
  • Start and stop provisioning jobs.
  • Manage deleted entities.
  • Configure Identity Provisioning in the SAP Cloud Identity Services administration console.

Adding a System

Overview

In this unit, you will learn - as an administrator - how you can set up the Identity Provisioning service so that entities from a source system are easily transferred to a target system.

Before triggering provisioning, make sure that you have performed the required setup.

You can perform the following operations:

  • Add source, target, and proxy systems
  • Set up configuration properties specific for your systems and scenarios
  • Define mapping rules between the data models of sources and targets
  • Provision entities between systems
  • Run and schedule provisioning jobs
  • View job logs
  • Export and import systems

Add a System

You can add source, target, and proxy systems in the Cloud Identity Services.

How to Configure Source Systems

This demonstration shows how to configure source systems. When you define a source system you detail what kind of system it is and you receive an initial template where you can adjust how entities (Users and Groups) should be read and, if needed, filtered or adapted. One simple example, which is now more than two decades old, is between ABAP-based systems. A user like DDIC or SAP* is very important in the context of an ABAP system, but there is no point in creating it has a user for Active Directory.

Steps

  1. Access the Identity Services UI and expand the Identity Provisioning menu. From there, you can view and configure Source Systems. Source Systems allow you to fetch users and their security attributes.

  2. Fill the details and if needed adjust the transformation rules.

How to Explore Target Systems

This demonstration shows how to manage target systems. At first glance, the definition of a target system is very similar to a source system, but some additional details appear, for example, the possibility of a target system receiving entities from multiple source systems and also the need to enrich entities' properties with missing details. For example, imagine that the target system requires a detail like the user organization. The source application might not provide it, but if it's mandatory in the target system, you need to at least place a default that later might be adjusted in the target application. When connecting and sharing the User-relevant data across many diverse systems, you might need to also adjust the corresponding schemas.

How to Explore Proxy Systems

This demonstration shows how to manage proxy systems. Proxy systems combine the characteristics of source and target systems. They read from a source system, provide a repository where entities can be stored in their own schema, and from where they can be sent to other target systems. While defining a proxy system, two transformations are generated, one for reading and the other one for writing, and both can be adjusted to address specific needs. Like in other transformations, the editor can be presented with a graphical interface or with a JSON coding interface.

How to Explore Administration Options

On-Premise Systems in SAP Cloud Identity Infrastructure

Set up the connection to on-premise systems, such as SAP AS ABAP, LDAP Server, Microsoft Active Directory, SAP S/4HANA On-Premise, when your Identity Provisioning bundle or standalone tenant is running on the SAP Cloud Identity Services infrastructure or SAP BTP.

Connecting to On-Premise Systems in SAP Cloud Identity Infrastructure

Set up the connection to on-premise systems when your Identity Provisioning bundle or standalone tenant is running on the infrastructure of SAP Cloud Identity Services.

Prerequisites

  • Ensure your tenant is running on SAP Cloud Identity Services infrastructure.
  • You have installed the Cloud Connector (for SAP BTP, Cloud Foundry environment) and have done the initial configuration.

Context

If your provisioning scenarios involve on-premise systems, this requires a separate configuration in three places:

  1. SAP BTP cockpit, where you subscribe to the Cloud Identity Services connectivity plan in your Cloud Foundry subaccount
  2. SAP Cloud Connector, where the connection to your Cloud subaccount is established, and the back-end (on-premise) system is defined
  3. Identity Provisioning administration console, where you configure the on-premise provisioning systems

Full and Delta Load

When you set up your systems and start a scheduled provisioning task, the standard behavior of the process reads all the entities from the source system. This mode prevents data loss and always keeps your target system synchronized with the source. However, it may take a long time for every job to be executed.

Delta read is a concept for optimizing the amount of data retrieved from the source system. Delta read is much faster, but sometimes might have limitations. In order for a source system to support delta read mode, its API should allow the implementation of this feature.

For example, the Microsoft Active Directory source system uses the uSNChanged attribute.

The main difference between delta and full read is as follows:

  • Delta read – only modified data is read from the source system and triggered to the target one. Modified data means new entities and updates on existing entities. Entities deleted from the source system will not be deleted from the target. They can be deleted only during a full read job.
  • Full read – all entities (new, updated, deleted, and existing unchanged ones) are read and checked every time a provisioning job is triggered to the target system.

To keep source and target systems completely synchronized, you can use the Resync type of provisioning job.

Note

We recommend that you enforce full reads from time to time if the connector is in delta read mode. To achieve this, you need to set up the following source system property: ips.full.read.force.count. For example, ips.full.read.force.count = 10 will result in alternating full reads after every 10 delta reads are performed.

This property only impacts scheduled runs; manually triggered runs are ignored. In case it is not set, only delta read jobs will be executed.

When the Identity Provisioning reads entities from a source system for the first time, it always triggers a full read job. If the job is successful, the service can then continue with delta read jobs (if such are activated). During a delta read job, the service reads only the entities that are new or have been modified after the last successful job.

The following table lists all source systems that currently support delta read mode.

Supported Systems

Supposed Systems

System TypeDetails
SAP SuccessFactors

Default mode: Delta read

You can switch to full read if you set up the relevant property: ips.delta.read = disabled

SAP SuccessFactors Learning

Default mode: Delta read

You can switch to full read if you set up the relevant property: ips.delta.read = disabled

LDAP-based Systems

System TypeDetails
Microsoft Active Directory

Default mode: Full read

You can switch to delta read if you set up the relevant property: ips.delta.read = enabled

Keep the following specifics and limitations in mind as you proceed:

  • In order to have a notion for any deleted objects in delta read mode, the Active Directory Recycle Bin optional feature must be enabled.
  • Make sure that the service user, which is used in the AD destination, has a Domain Admin role, otherwise the connector won't be able to extract any data from the recycle bin.
  • Due to the linked attributes concept of AD, there is a limitation in the Microsoft Active Directory read connector when performing in delta read mode. We recommend that you enforce full reads periodically in order to avoid data loss.
  • You need to set limitations about which particular attributes are read. For this purpose, set the properties ldap.user.attributes and ldap.group.attributes and add uSNChanged to the attributes list. Otherwise, the provisioning job will run in full read mode.

SCIM-based Systems

System TypeDetails
Identity Authentication

Default mode: Full read

You can switch to delta read if you set up the relevant property: ips.delta.read = enabled

Note

When using SAP Central Business Configuration and Identity Directory SCIM API (in short, SCIM API version 2), delta read mode is only supported for user resources.

For delta read of resources (users and groups), remember the following API requirements:

  • The system API should return lastModified, which is a subattribute of the meta attribute. The lastModified subattribute denotes the most recent date and time when the resource details were updated at the service provider.
  • The system API has to also support filtering by the lastModified attribute, and the system should support the gt operator in filter expressions.
Local Identity Directory
SAP Central Business Configuration
SAP CPQ

SCIM System

(General SCIM system, if fulfills the API requirements)

How to Explore Real-Time Provisioning

This demonstration shows how to access the real-time provisioning configuration screens. Besides the schedule transfer of entities across different systems, like Users and Groups, you might need to immediately make a new User or Group available. Here you find where to define a system candidate for real-time provisioning and explore some of the available options for authentication into the recipient (target) system where the new entities will be created, from Basic Authentication to Certificates, even if OAuth is now a widely common method.

Provisioning Job - Start and Stop

You can start and stop a provisioning job from the Identity Provisioning administration console or from an API client by using the Identity Provisioning tenant admin API.

Prerequisites

  • Your source and target systems are configured and enabled.
  • (Optional) You have run a Simulate and/or a Validate job before you run the actual provisioning job to verify that Identity Provisioning configurations produce the desired result in the target systems.

Job Types

The Identity Provisioning service provides the following types of provisioning jobs:

Types of Provisioning Jobs

Run FromJob TypeReal Provisioning
Admin console

Read Job - Reads all entities from the source system and provisions only new or updated entities to the target system. If the job is run in delta read mode, it reads and provisions only new or updated entities in the source system.

Yes

Resync Job - Reads all entities from the source system and provisions all entities to the target system.

Simulate Job - Estimates the number of entities that will be created, updated, deleted, or skipped in the target system. Provides the expected results of a resync job without modifying the target system.

No

Validate Job - Verifies how entities (users and groups) would be mapped from source to target systems without modifying them.

API client

Use the Identity Provisioning tenant admin API to run a provisioning job from an API client. The API is available on the SAP API Business Hub.

Yes

Start a Job

To run a job, select a source system and choose Jobs  <Job_Type> and Run Now.

Schedule a Job

To schedule a job run, select a source system and choose JobsRead JobSchedule.

Stop a Job

To stop a running job, select a source system and choose the Stop Job button in the Action column.

Manage Deleted Entities

Manage the deletion of entities (users or groups) in the target system after they have been deleted from the source system.

Scenarios and Solutions

ScenarioSolution

Scenario 1

An entity exists both in the source and the target system.

  1. You run a provisioning job for the first time.

    As a result, Identity Provisioning reads this entity from the source and updates it on the target system.

  2. You delete the relevant entity from the source system.
  3. You run another provisioning job which finishes successfully.

    However, the service recognizes the relevant entity as a "previously existed one" and does not delete it from the target.

The following sequence of steps is recommended for synchronizing the deletion of entities between source and target systems, as in Scenarios 1, 2 and 3:

You have run successful provisioning jobs (Read or Resync) between the systems.

  1. Delete an entity from the source system.
  2. On the Properties tab of the target system, add the ips.delete.existedbefore.entities property and set its value to true.
  3. Run a provisioning job.
  4. Verify that the relevant entity has been deleted from the target system.

If the property is set afterward, entities recognized as "previously existed ones" cannot be deleted from the target system anymore. In this case, you need to delete them from the target system (for example, manually or through a script).

The ips.delete.existedbefore.entities is an optional property that can be set on every target system. You can use it to control whether recognized entities as "previously existed ones" should be deleted from the target system.

This is important for security and legal reasons in cases when users (for example, employees) are no longer active in the source system, and their availability and permissions must be removed from the relevant target systems.

Scenario 2

An entity does not exist in either system (neither source, nor target).

  1. You run provisioning jobs (Read or Resync) between the systems.
  2. You add this entity to the source system.
  3. The same entity is added (manually or through script) to the target system.
  4. You run a new provisioning job.

    As a result, Identity Provisioning reads this entity from the source and updates it in the target system.

  5. You delete the relevant entity from the source system.
  6. You run another provisioning job which finishes successfully.

    However, the service recognizes the relevant entity as a "previously existed one" and does not delete it from the target.

Scenario 3

An entity exists in the source system only.

  1. You run at least one provisioning job.

    As a result, Identity Provisioning reads this entity and creates it in the target system.

  2. You reset one of these systems.
  3. You run a new provisioning job.

    As a result, Identity Provisioning reads this entity from the source system (but is not "aware" of it, that is, it behaves like it is reading it for the first time) and makes a full update of it in the target system.

  4. You delete the relevant entity from the source system.
  5. You run another provisioning job which finishes successfully.

    However, the service recognizes the relevant entity as a "previously existed one" and does not delete it from the target.

Scenario 4

An entity exists both in the source and the target system. (It has not been created on the target by the Identity Provisioning service.)

Conditions or expressions, such as (ignore or skipOperations), are not set in the target transformation.

  1. You run a successful Read job. As a result, Identity Provisioning updates the existing entity on the target system.
  2. You delete this entity from the source system.
  3. You run a provisioning job which finishes with error.

    As a result, the relevant entity has not been deleted from the target system.

  4. In the job log, you see that there are failed entities (users or groups) on the source system. That means that the job has failed trying to read them from the source.
  1. Resolve the failed entities in the source system.
  2. On the Properties tab of the target system, add the ips.delete.existedbefore.entities property and set its value to true.
  3. Run a successful Read job between the systems.
  4. Verify that the relevant entity has been deleted from the target system.

    Note

    Even if the job fails due to errors on the target system, if the read from the source is successful, the service will still delete the entity from the target.

Scenario 5

An entity exists in the source system and has been provisioned to the target by the Identity Provisioning service.

Conditions or expressions, such as (ignore or skipOperations), are not set in the target transformation.

  1. You delete this entity from the source system.
  2. You run a provisioning job which finishes with error.

    As a result, the relevant entity has not been deleted from the target system.

  3. In the job log, you see that there are failed entities (users or groups) on the source system. This means that the job has failed trying to read them from the source.
  1. Resolve the failed entities in the source system.
  2. Run a successful Read job between the systems.
  3. Verify that the relevant entity has been deleted from the target system.

    Note

    Even if the job fails due to errors on the target system, if the read from the source is successful, the service will still delete the entity from the target

Scenario 6

An entity exists in the source system and has been provisioned to the target by the Identity Provisioning service.

Conditions or expressions, such as (ignore or skipOperations), are not set in the target transformation.

  1. You delete an entity from the source system.
  2. You run a delta read job which finishes successfully.

    However, the relevant entry has not been deleted from the target system. That is because delta read jobs do not take deleted users into consideration. To learn more, see Manage Full and Delta Read (the link for which is here: https://help.sap.com/docs/IDENTITY_PROVISIONING/f48e822d6d484fa5ade7dda78b64d9f5/b7f817cbcf964819a23f0a2bcbd18c95.html).

  1. On the Properties tab of the source system, set the ips.delta.read property to false.

    Alternatively, you can wait for the next scheduled full job to start (if it is coming soon), according to the number you have set for property ips.full.read.force.count.

  2. Run a new provisioning job (or wait for it to run automatically). It will be a full read job.
  3. Verify that the relevant entity has been deleted from the target system.
  4. (Optional) If you want to continue running delta read jobs, go to the ips.delta.read property and set it back to true.

Identity Provisioning in the SAP Cloud Identity Services Administration Console

Administrators of Identity Provisioning tenants running on SAP Cloud Identity infrastructure can configure and work with the provisioning functionality in the administration console of SAP Cloud Identity Services (formerly known as the administration console of Identity Authentication).

Prerequisites

  • The Identity Provisioning service must be enabled for your Identity Authentication tenant.
  • The Manage Identity Provisioning permission must be enabled for the Identity Authentication and Identity Provisioning administrator.

Context

Identity Provisioning is embedded in the SAP Cloud Identity Services administration console. The entire provisioning functionality can be accessed there in the navigation area under Identity Provisioning. Regardless of where you choose to configure your source, target, and proxy systems and run jobs, the functionality itself remains the same.

Sharing one administration console is a step further in tightening the SAP Cloud Identity Services integration.

To navigate from Identity Provisioning to SAP Cloud Identity Services administration console and configure provisioning, proceed as follows:

  1. Log on to the Identity Provisioning admin console and go to SecurityAuthorizations.
  2. Choose Manage User Authorizations.

    You are redirected to the SAP Cloud Identity Services admin console, section Users and AuthorizationsAdministrators.

  3. In the navigation area, select Identity Provisioning and proceed with your configuration.

Note

Alternatively, you can switch back and forth between both admin consoles by modifying the tenant URLs. For example, to navigate from Identity Provisioning to SAP Cloud Identity Services, replace the ips part of the tenant URL with admin as follows: https://<ias-host>/ips → https://<ias-host>/admin. To navigate back, replace admin with ips. In the latter case, there is no way to navigate from SAP Cloud Identity Services to Identity Provisioning through the user interface.

Log in to track your progress & complete quizzes