Identifying Provisioning Services Operations

Objectives

After completing this lesson, you will be able to:

  • Add source, target, and proxy systems
  • Search and edit source, target, and proxy systems in the Identity Provisioning user interface
  • Delete a system
  • Enable and disable systems
  • Export and import systems
  • Update connector version
  • Manage authorizations in SAP Cloud Identity infrastructure
  • Create a technical user
  • Manage transformations, properties, and certificates
  • 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

System Addition

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
  • Configure the frequency of the provisioning processes
  • Run and schedule provisioning jobs
  • View, maintain and delete job logs
  • Enable and disable systems
  • Export and import systems
  • Reset the Identity Provisioning UI configurations
  • Deactivate the Identity Provisioning service

Add a System

You can add source, target, and proxy systems to the Identity Provisioning UI.

Context

To provision entities (users, groups, roles) from one system to another across your enterprise, you first need to add and configure these systems as source and target connectors in the Identity Provisioning user interface.

The maximum number of systems you are allowed to add is as follows:

  • 20 sources systems
  • 50 target systems

If your business requires using more systems, create an incident for component BC-IAM-IPS to request them. Describe your scenarios and provide a reason why you need the additional systems.

When you add a system, it is created with its default properties and transformations. If the system has different versions (based on the APIs it provides), you can specify which one you want to use, so that the system is created with the version specific properties and transformations.

Versioning is supported for Identity Authentication, SAP SuccessFactors, SAP Concur, SAP Analytics Cloud, and SAP Sales Cloud, and SAP Service Cloud. It is controlled by the <system prefix>.api.version property.

To Add a System

To add a system, complete the following steps.

Steps

  1. From the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  2. Choose the Add button at the bottom of the left-hand panel.

  3. On the Details tab, provide the following information:

    Details tab

    FieldDescription
    TypeSelect the system type that you want to configure.
    System Name

    Add a name for your system. Make sure it does not duplicate another system's name in the UI.

    Note

    System names can have a length of up to 100 characters. Only the following characters are allowed: (a-z), (A-Z), (0-9), (-), (_), (.) and spaces.

    Destination Name

    (Optional) Select a destination.

    If you have previously created a connectivity destination in SAP BTP cockpit on subaccount level, you can access it from the Identity Provisioning UI.

    Note

    • When you select a connectivity destination, it must be compliant to the relevant system type.
    • The destination should specify all the connection settings required for your identity provisioning scenario.
    • For SAP Application Server ABAP systems, creating a destination is mandatory.

    If you skip the Destination Name field, you can enter the connection and configuration properties needed for your scenario on the Properties tab.

    Note

    • If you use both a connectivity destination and the Properties tab, and one and the same property exists in both places, the value set in the Properties tab will be considered with higher priority.

    • If you leave both the Destination Name field and the Properties tab empty and then run a job, no identity provisioning will be performed.
    Description(Optional) Enter a description. It will help you easily distinguish your systems in the list later.
    Source Systems

    This field is displayed only for target systems.

    Select a source system whose identities you want to read and provision to the target one. You can select multiple source systems.

    Note

    If you had previously added one or more source systems, but some of them were later deleted in your Identity Provisioning UI, an error message will appear. To correct this inconsistency, edit the target system configuration (select active source systems), and save the changes.

  4. Choose Save, if the system you add has no version, or it has two or more versions and you want the default one. The new system appears in the left-side panel. The default transformations and properties are displayed under the respective tabs.

    Do not choose Save, if the system you add has two or more versions and you want to specify a particular one. In this case, proceed as follows:

    • From the Details tab (without saving your configurations), move to the Properties tab and select it.
    • Add the API version property for your system and a value. For example, if you add SAP SuccessFactors on the Details tab, add sf.api.version and the desired version 2.
    • Now, choose Save.

    This creates an SAP SuccessFactors system with specific properties and transformation for version 2, which is based on SAP SuccessFactors Workforce SCIM API. Providing value 1 would result in creating a system with specific properties and transformation for version 1, which is based on SAP SuccessFactors HCM Suite OData API.

    Note

    When you save your configuration, switching between versions is possible but requires manual work, mostly adding the version specific properties and transformations.

    To add connection and configuration properties, choose Properties Edit.

  5. To modify your default system transformation (if needed), choose Transformations Edit.

  6. Save your changes.

    At the end of the Identity Provisioning URL, a dash-separated string appears. This is the automatically generated unique ID of the newly created system.

To Search and Edit a System

Admin users can search and edit source, target, and proxy systems in the Identity Provisioning user interface.

To use the search field, your Identity Provisioning tenant must run on SAP Cloud Identity infrastructure.

Steps

  1. From the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  2. From the list on the left, directly select a system or search for it and select it.

  3. Select a tab and edit the configurations:

    • Details
    • Transformations
    • Properties
    • Certificates

  4. Choose the Edit button and make your changes.

  5. Save your changes.

To Delete a System

We will now explain how you can delete source and target systems in the Identity Provisioning UI.

Context

This topic explains how you can delete a source, target, or proxy system in the Identity Provisioning UI.

Note

Before you delete a system, make sure you do not need it anymore. If you think you might need it in future, export it first as a JSON or a CSV file.

To delete a system, proceed as follows:

Steps

  1. From the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  2. From the list on the left, select a system.

  3. Choose Edit from the top of the systems panel.

  4. At the bottom of the panel, choose the Delete button.

  5. In the dialog box, confirm this with OK.

  6. Save your changes. The system disappears from the panel.

To Enable and Disable Systems

This topic explains how you can enable and disable source and target systems in the Identity Provisioning UI.

To use a system for provisioning purposes, its status has to be set to Enabled. When you add a new system, it is enabled by default. If one of your added systems is configured and you currently do not need it, but would like to use it later, you can disable it.

Steps

  1. From the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  2. From the list on the left, select a system.

  3. Choose Edit from the top of the systems panel.

    • If the system is currently disabled, choose the Enable button and confirm with OK.
    • If the system is currently enabled, choose the Disable button and confirm with OK.

  4. Save your changes.

Overview and Context

Overview

We will now explain how you can export and import source, target, and proxy systems in the Identity Provisioning UI.

Context

If you have added and configured a system, you can export it for further use. The export-import function comes in handy in the following use cases:

  • You need to back up your system before updating to a new connector version.
  • You need another system of the same type but with slightly different setup, and you do not want to manually enter all data and configuration properties all over again.
  • You need to reuse an existing system in the Identity Provisioning UI but for another subaccount.
  • You have reached the maximum number of systems you are allowed to add. You need to add one more system, which means you must delete some of the previous ones. However, you do not want to lose their configurations; thus you export these systems.

Delete a System

Activate the following video and audio to learn about how to delete a system.

ExerciseStart Exercise

To Export a System

To export a system, complete the following steps.

Steps

  1. From the UI home page, choose a section such as the following: Source Systems, Target Systems, or Proxy Systems.

  2. From the list on the left, select the system that you want to export.

  3. Choose the Export button.

  4. The exported system configuration depends on your scenario. If your system is a source or a target one, it will be exported as a JSON file. If it is a proxy one, you have two options:

    • Select JSON format – the system configuration will be exported as a .json file, which you can later import back in the Identity Provisioning UI.
    • Select CSV format – the system configuration will be exported as a .csv file, which you can later import in the SAP Identity Management UI as a SCIM repository.

  5. Save the file on your local file system.

To Import a System

To import a system, complete the following steps.

Steps

  1. From the UI home page, choose a section: Source Systems, Target Systems, or Proxy Systems.

  2. Choose the Add button.

  3. In the section, Define from File, choose the Browse button.

  4. Browse and select the file with the system configuration that you need on your local file system. You can import files with extension .json as well as files with no extension.

  5. The system configuration is displayed in the Details editor. You can also see the imported transformations and properties of this system in the respective UI tabs.

  6. Change the System Name, otherwise an error message will appear warning you that a system with this name already exists.

  7. The Properties tab will prompt you to enter the credentials (like passwords or client secrets). When you export a system, credentials are skipped (not displayed as plain text in the .json file). Therefore, when you import it, you have to manually enter the passwords/secrets.

  8. Save your changes.

    The imported system appears in the left-side panel. Its ID is different than the one of the "original" system (you can see it in the URL).

    Caution

    You cannot export a target system and import it back as a source, not the other way around.

Export a System

Activate the following video and audio to learn about how to export a system.

ExerciseStart Exercise

Import a System

Activate the following video and audio to learn how import a system.

ExerciseStart Exercise

Connector Version Update

Update a connector version to allow your provisioning system to use a new API.

Context

When an SAP cloud solution or service provides a new API for integrating with Identity Provisioning, you can update your respective connector (provisioning system) to use this API by configuring a version property and replacing its transformations.

For example, SAP Sales Cloud and SAP Service Cloud (formerly known as SAP Cloud for Customer) initially provided two SOAP-based APIs for integrating with Identity Provisioning and later introduced a SCIM-based API. Likewise, Identity Authentication service initially provided a SCIM-based API and later introduced an Identity Directory SCIM API.

Version property set to 1 means that your connector is using the initial API. You can continue using it as-is or update your connector to a new version.

Note

Before updating your connector to a new version.

To Update a Connector Version

To update your connector to use a new API, complete the following steps.

Steps

  1. From the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  2. From the list on the left, select a system.

  3. On the Properties tab, configure the following:

    1. Add the <system_prefix>.api.version property and set its value accordingly:

      Properties

      ConnectorPropertiesValue
      Identity Authenticationias.api.version
      • 1 - Identity Authentication SCIM API (in short, SCIM API version 1)

        Note

        When the property is not defined - Identity Authentication SCIM API is used.
      • 2 - Identity Directory SCIM API (in short, SCIM API version 2)
      SAP Concurconcur.api.version
      • 1 - SAP Concur API (Version 1)

        Note

        When the property is not defined - SAP Concur API is used.
      • 2 - SAP Concur SCIM API (Version 2)
      SAP Sales Cloud and SAP Service Cloudc4c.api.version
      • 1 - Version 1 (SOAP-based API)

        Note

        The SOAP-based API version 1 is deprecated.
      • 2 - Version 2 (SOAP-based API)
      • 3 - Version 3 (SCIM 2.0 based API)
      SAP SuccessFactorssf.api.version
      • 1 - SAP SuccessFactors HCM Suite OData API (Version 1)

        Note

        When the property is not defined - SAP SuccessFactors HCM Suite OData API is used.
      • 2 - SAP SuccessFactors Workforce SCIM API (Version 2)
      SAP Analytics Cloudsac.api.version
      • 1 - SAP Analytics Cloud SCIM API version 1. This is the default value.
      • 2 - SAP Analytics Cloud SCIM API version 2

    2. If there are properties with version-specific value, provide the proper value for the respective version. For example, the value of the SAP SuccessFactors URL and sf.user.filter properties differ in version 1 and 2.

  4. On the Transformations tab, if you have customized your transformation logic, copy and save it first, and then replace it with the transformation provided for the respective API version.

    Use the Identity Provisioning connector documentation as a source of information for the transformation you need.

  5. Reset the system to clear the operation data. It is assumed that you have already run provisioning jobs to target systems.

    1. If you reset a target system, set the ips.delete.existedbefore.entities to true. This ensures that if from now on you delete entities in the source system that is connected to your target system, those entities will be recognized as previously existed entities in the target system and will be deleted there.

    2. If you reset a source system, set the ips.delete.existedbefore.entities to true in every target system connected to the given source system. This ensures that if from now on you delete entities in the source system that is connected to your target system, those entities will be recognized as previously existed entities in the target system and will be deleted there.

  6. Adapt your new transformation, that is, apply the customizations from your previous transformation.

  7. Save your changes and run a provisioning job.

Manage Authorizations

Manage the authorizations of Identity Provisioning administrators, when your bundle or standalone tenant is running on SAP Cloud Identity Services infrastructure or SAP BTP, Neo Environment.

You can request administrative access for your Identity Provisioning bundle or standalone tenant, add additional users as administrators of the tenant and create a technical user with the necessary authorizations for configuring real-time provisioning and proxy systems.

Prerequisites

  • Ensure your tenant is running on SAP Cloud Identity Services infrastructure.

Note

When the Identity Provisioning tenant is initially provisioned to your organization, only one user is added as a tenant administrator. After that, due to possible legal and security issues, SAP adds additional tenant administrators only in exceptional cases (for example, the existing administrator left the company, or for some reason there is no active administrator for this tenant).

To avoid access-related issues in such cases, it is always a good practice for you to assign more than one administrator. Adding additional ones is exclusively in the responsibility of the current tenant administrators. For more information, see the Add Additional Admin Users in the following section.

To Get Administrative Access

To get administrative access for the Identity Provisioning tenant, complete the following steps.

Steps

  1. Log on to the Identity Authentication admin console and navigate to Users and Authorizations and Administrators.

  2. Add an administrator of type User and enable the Manage Identity Provisioning role.

    You are now granted the main IPS_ADMIN role.

  3. Save your changes.

To Add Additional Admin Users

To add additional users as administrators of the Identity Provisioning tenant, complete the following steps.

Steps

  1. Log on to the Identity Provisioning admin console and go to Security Authorizations.

  2. Choose Manage User Authorizations.

    You are redirected to the Identity Authentication admin console, section Users and Authorizations Administrators.

  3. Add the new administrator of type User and enable the Manage Identity Provisioning role.

    This administrator is now granted the main IPS_ADMIN role

  4. Save your changes.

To Create a Technical User

To create a technical user with the necessary authorizations for configuring real-time provisioning and proxy systems, complete the following steps.

Steps

  1. Log on to the Identity Provisioning admin console and go to Security Authorizations.

  2. Choose Manage User Authorizations.

    You are redirected to the Identity Authentication admin console, section Users and Authorizations Administrators.

  3. Add the new administrator of type, System.

    This is the technical user you can use for configuring provisioning scenarios with proxy systems and real-time provisioning.

  4. In the Configure System Authentication screen, configure certificate-based authentication or basic authentication for the technical user.

  5. Assign the necessary authorizations (roles) to the new user.

    Role and Description

    RoleDescription
    Access Proxy System API

    Authorizations to access API for provisioning identities using proxy systems.

    This role is needed for provisioning scenarios where proxy systems in the Identity Provisioning admin console are configured for synchronizing user data to and from central identity management solutions (such as the on-premise SAP Identity Management).

    In this case, you use the credentials of the admin user with Access Proxy System API role assigned for setting up the technical user in the identity management solution for communicating with Identity Provisioning.

    Access Real-Time Provisioning API

    Authorizations to access API for real-time provisioning of identities.

    This role is needed for provisioning scenarios where user data is provisioned real-time without running jobs (manual or scheduled ones) in Identity Provisioning.

    In this case, you use the credentials of the admin user with Access Real-Time Provisioning API role assigned for setting up the authentication mechanism of the provisioning system defined on the User Provisioning screen in the Identity Authentication admin console.

    Access Identity Provisioning Tenant Admin API

    Authorizations to access tenant API for running provisioning jobs.

    This role is needed for running provisioning jobs from an API client.

    The API is available on the SAP API Business Hub. The URL for accessing the Tenant Admin API follows the pattern: https://<IPS tenant host>/ips/publicapi/v1/startJob/{SourceSystemId}/jobs/{JobType}

  6. Save your changes.

To Manage Transformations

You can manage transformations with graphical and JSON text editor. Regardless of which one you choose, the following initial steps are the same.

Steps

  1. Access the Identity Provisioning administration console.

  2. From the UI home page, choose a tile: Source Systems, Target Systems, or Proxy Systems.

  3. Select a system from the left panel and go to the Transformations tab.

    The graphical editor is displayed by default. You can switch to the JSON editor by choosing the code-bracket icon.

  4. Choose Edit.

    You need to work in edit mode to add, modify, and delete entities and their configurations.

    • Working with the JSON editor allows you to type changes and perform operations like select, cut, copy, and paste the transformation code.
    • Working with the graphical editor allows you to graphically model your changes.

  5. Save your changes.

Manage Transformations

Activate the video and audio to learn how transformations can be edited.

ExerciseStart Exercise

To Manage Properties

You can add, delete, and modify properties for a system in the Identity Provisioning UI.

Prerequisites: You have added a system (source, target, or proxy) in the Identity Provisioning user interface. 

Steps

  1. Access the Identity Provisioning User Interface (UI).

  2. From  the UI home page, choose a tile – Source Systems, Target Systems, or Proxy Systems.

  3. Select a system from the left panel and go to the Properties tab.

  4. To modify the current properties, choose Edit in the bottom right corner.

  5. Add the properties required by your scenario to make a successful connection to the selected system. You can use two types of properties:

    • Standard: These are properties, whose values are displayed as numbers or plain text strings - for example, Type, ProxyType, URL, Authentication.
    • Credential: These are properties whose values contain sensitive information that must not be displayed as plain text - for example: Password (standard passwords, private keys, or OAuth client secrets), ssh.private.key (relevant to SSH Server), hana.jdbc.ssh.tunnel.private.key (relevant to SAP HANA Database).

  6. Save your changes.

Manage Certificates

Identity Provisioning supports certificate-based authentication for secure communication with the provisioning systems (connectors) provided by the service.

Context

Certificates can be used in outbound and inbound connections to Identity Provisioning.

In outbound connections, Identity Provisioning acts as an SSL client. The service generates an X.509 client certificate for mutual Transport Layer Security (mTLS) authentication against a given provisioning system acting as a server. The Identity Provisioning client certificate must be uploaded to the given provisioning system for configuring the certificate-based authentication there. For example, in SAP BTP ABAP Environment, the Identity Provisioning certificate must be uploaded to the communication user used in the communication arrangement.

In inbound connections, Identity Provisioning acts as a server whereas the given provisioning system acts as a client and must present a client certificate for establishing the communication to the service. Customers of bundle and standalone tenants running on SAP BTP, Neo Environment import client certificates in the Identity Provisioning admin console. Customers of bundle and standalone tenants running on SAP Cloud Identity infrastructure upload the client certificates in the Identity Authentication admin console on the technical user of type System.

Inbound certificates are supported for source and proxy systems in the following scenarios: configuring proxy systems and real-time provisioning.

Note

Client certificate authentication is not supported for systems where the ProxyType and ldap.proxyType properties, required for the HTTP and LDAP connection respectively, are set to OnPremise.

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, Neo Environment.

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 Foundry subaccount is established, and the backend (on-premise) system is defined.
  3. Identity Provisioning administration console, where you configure the on-premise provisioning systems.

To Connect to On-Premise Systems

To connect to on-premise systems, complete the following steps.

Steps

  1. Before you start the actual configuration, access the SAP Cloud Identity Services - Tenants application at the following URL: https://iamtenants.accounts.cloud.sap/. This allows you to view the region and the type of Identity Authentication and Identity Provisioning tenants assigned to your customer ID. You will need this information later when you are creating the Cloud Foundry subaccount.

    The following figure illustrates a customer landscape with Identity Authentication and Identity Provisioning tenants running on their common SAP Cloud Identity Services infrastructure in one region - US/Canada (in the red frame). The first pair is used for testing purposes and the second one is used for productive purposes.

  2. Log on to SAP BTP cockpit and choose your global account.

    If you only have one global account, you are automatically taken there. If you have multiple ones, select the global account you want to set up connection to on-premise system.

  3. Create a subaccount in the Cloud Foundry region that maps the region of the Identity Authentication tenant (where the Identity Provisioning is also running). View the following mapping table.

    Cloud Foundry Region

    Identity Authentication RegionCloud Foundry Region
    Rot (Germany) / Amsterdam (Netherlands)Europe (Frankfurt) AWS
    Germany (Frankfurt)Europe (Frankfurt) AWS
    UAE (Dubai)Europe (Frankfurt) AWS
    Saudi Arabia (Riyadh)Europe (Frankfurt) AWS
    Australia (Sydney) / Japan (Tokyo)Australia (Sydney) AWS
    China (Shanghai)Singapore AWS
    SingaporeSingapore AWS
    South Korea (Seoul)South Korea (Seoul) AWS
    Japan (Tokyo) / Japan (Osaka)Japan (Tokyo) AWS
    Brazil (São Paulo)Brazil (São Paulo) AWS
    United States (Sterling) / Canada (Toronto)US East (VA) AWS
    Canada (Toronto)Canada (Montreal) AWS
    USA West (Quincy)US West (WA) Azure

  4. For example, customers with Identity Authentication and Identity Provisioning tenants in US/Canada region must create a Cloud Foundry subaccount in US East (VA) region.

  5. When you create the subaccount, you must enable Cloud Foundry for this subaccount.

  6. If you already have a Cloud Foundry subaccount, you can use it.

  7. Open your subaccount, and from the left-side panel choose Service Marketplace → Integration Suite → Cloud Identity Services.

  8. Choose Create, select the connectivity plan, and choose Next.

    If the connectivity plan is not present, navigate to Entitlements → Configure Entitlements → Add Service Plans. Search for Cloud Identity Services → connectivity plan, and add it as service plan and save your changes.

    You can create only one subscription plan per subaccount. This means that you cannot have connectivity along with additional-tenant plan in the same subaccount.

  9. From the Cloud Service Type dropdown, choose for what type of tenant (test or productive) you want to use the subaccount.

    • Test
    • Productive - default value

  10. Choose Next and Create.

    This creates a subscription to the Cloud Identity Services connectivity plan and creates a binding to your Identity Authentication tenant and your Identity Provisioning service.

    Note

    You can have two separate Cloud Foundry subaccounts per region: one of them configured for Productive connections and the other for Test connections. While it is allowed to create multiple Cloud Foundry subaccounts per one region and per one type (test or productive), be aware that in this case only the first one where the connectivity plan was enabled will be used by Identity Provisioning.

  11. Now, you need to add and connect your subaccounts to the Cloud Connector. Log on to the Cloud Connector administration UI and choose Add Subaccount.

  12. Verify that the Cloud Connector is connected to your Cloud Foundry subaccount. In SAP BTP cockpit, from the left-side panel, choose Connectivity → Cloud Connectors to see your up and running cloud connector tunnels.

  13. Return to the Cloud Connector and define the backend (on-premise) system.

  14. Return to your subaccount in SAP BTP cockpit and navigate to Connectivity → Destinations to configure the destination for your on-premise system.

    Note

    This step is mandatory only for SAP Application Server ABAP.

  15. Log on to your Identity Provisioning admin console.

    The URL follows the pattern: https://<tenant_id>.accounts.ondemand.com/ips

  16. Add an on-premise system (source, target, or proxy).

  17. If you want to create a connection to SAP AS ABAP, from the Destination Name combo box, select the destination you have created in the cockpit and save your configurations.

    If you want to create a connection to other on-premise systems, configure the connection details on the Properties tab of the given system.

  18. (Optional) If your Cloud Connector is configured with Location ID, this location identifier must also be set for the respective on-premise system. You have the following options:

    • Connectivity destination - Create it in your subaccount in the SAP BTP cockpit and provide the Location ID there.

    Note

    Using connectivity destination is mandatory only for SAP Application Server ABAP.
    • CloudConnectorLocationId property - Configure the property in the Identity Provisioning admin console for all HTTP and LDAP-based systems, SSH Server (Beta) and SAP HANA Database (Beta) with ProxyType set to OnPremise.
    • Alternatively, for HTTP-based systems only, you can add the Identity Provisioning ips.http.header.<header_name> property, where the header name is: SAP-Connectivity-SCC-Location_ID and the value is the Location ID. For example: ips.http.header.SAP-Connectivity-SCC-Location_ID=<LocationID>

  19. Add another provisioning system, connect it to your on-premise one, and run a provisioning job.

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 to be 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)

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 Jobs → Read Job → Schedule.

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 system(s).

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 Security → Authorizations.
  2. Choose Manage User Authorizations.

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

  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