Knowledge Article

SAP Identity Directory

Author

  • sachintaware

    SailPoint

Introduction

The SAP Identity Directory serves as the foundational component for storing user and group information within the SAP Cloud Identity Services infrastructure. It acts as the authoritative source for users who have or will have access to SAP cloud applications. In essence, the Identity Directory functions as the persistence layer for SAP Cloud Identity Services.

The SAP Identity Directory provides a system for Cross-domain Identity Management (SCIM) 2.0 REST API, enabling programmatic management of resources such as users, groups, and custom schemas. The attributes for these resources adhere to the SCIM 2.0 core schema and the enterprise user resource schema. Furthermore, custom attributes are supported through schema extensions for customer specific requirements

System landscape

The SAP Identity Directory plays a crucial role in streamlining customer interactions with multiple SaaS-based applications within a typical SAP landscape. SAP strongly recommends using it as a central access point for SAP cloud environments.

By storing users centrally in the Identity Directory, organizations ensure a well-defined user lifecycle. Moreover, it serves as the cornerstone for seamless integration with SAP Cloud Identity Access Governance and SAP Task Center, both of which rely on the Identity Directory as a best practice.

Typical SAP CIS landscape representing Identity directory

An essential benefit of this approach is its suitability for customers with existing non-SAP identity management solutions in their landscape. By storing users in the Identity Directory and leveraging Identity Provisioning services, seamless integration with the SAP landscape is achieved.

Once integration with the cloud identity service is complete, identities can be provisioned across all connected systems. Identity Provisioning facilitates reading entities from user stores such as Microsoft AD and SAP Identity Management, replicating them to the directory, and subsequently provisioning them to desired connected systems.

Identity directory in conjunction with Identity provisioning

Spoiler (Highlight to read)Please note that the SAP ID service and the Identity Directory are distinct. The SAP ID service is fully managed by SAP and is specifically designed for interactions with other SAP applications, including BTP accounts, support tickets, and community postings. In contrast, the Identity Directory instance is entirely managed by the customer.Please note that the SAP ID service and the Identity Directory are distinct. The SAP ID service is fully managed by SAP and is specifically designed for interactions with other SAP applications, including BTP accounts, support tickets, and community postings. In contrast, the Identity Directory instance is entirely managed by the customer.

Global User ID

The Global User ID (userUUID) serves as an immutable and unique identifier across technology layers. It facilitates the correlation of identities across different products and lines of business within an enterprise.

When a new user is created, the SAP Identity Directory generates the Global User ID (which can also be generated externally). Subsequently, the SAP Identity Provisioning service distributes this Global User ID to SAP cloud applications, such as SAP Task Center, which require a consistent identity identifier for integration scenarios.

SAP recommends using the Global User ID from SAP Cloud Identity Services as the federation identifier.

SAP Identity Directory (Local Identity Directory)

To gain a better understanding of local identity, consider a typical use case that complements Identity Provisioning. While Identity Provisioning primarily handles user and group provisioning, it can also store these entities in a specialised system known as the SAP Identity Directory. In this scenario, the SAP Identity Directory is initially configured as a target system, where users and groups are provisioned. Subsequently, it is configured as a source system, allowing users and groups to be read and provisioned to other target systems.

The SAP Identity Directory serves as a mediator between the source and target systems.

Benefits of Using SAP Identity Directory

Key benefits include:

  • Fast adoption of SAP solutions through out-of-the-box integrations
  • Rapid scenario extensions with optimised SAP connectors
  • Reduced point-to-point connections effort
  • Modular architecture
  • Standard integration with SAP Identity Management available
  • SCIM compatible integration with 3rd party Identity Management solutions
  • Optimised connectivity for the SAP BTP applications

SAP Identity Directory business use-cases:

1. Classic use case

Spoiler (Highlight to read)Here, the SAP Identity Directory can be configured both as a target and as a source.Here, the SAP Identity Directory can be configured both as a target and as a source.

In this commonly used scenario, the SAP Identity Directory is initially configured as a target system for provisioning users and groups. Subsequently, the same SAP Identity Directory is configured as a source system, allowing users and groups to be read and provisioned to other target systems.

Source system: SAP SuccessFactors

Target system: Microsoft Entra ID

LID-3.png

Below are quick simple steps to achieve the same with example systems mentioned below :

  1. Add SAP SuccessFactors as a Source System:
    1. Navigate to identity provisioning in Cloud Identity Services.
    2. Add SAP SuccessFactors as a source system.
  2. Configure SAP Identity Directory as a Target System:
    1. Set up SAP Identity Directory as the target system.
    2. Specify SAP SuccessFactors as the source.
  3. Optional: Define Transformation Logic:
    1. If needed, create transformation logics for data mapping.
  4. Run Provisioning Jobs for SuccessFactors:
    1. Execute provisioning jobs to synchronize users from SuccessFactors to SAP Identity Directory.
  5. Add SAP Identity Directory as Source for Entra ID:
    1. Finally, configure SAP Identity Directory as the source system and Entra ID as the target.
    2. Provision users accordingly.

Spoiler (Highlight to read)The benefit of using SAP Identity Directory in this scenario is we don't have to enter connection properties again. Also filters can be effectively used to provision required set of users ( ex. idds.group.filter )The benefit of using SAP Identity Directory in this scenario is we don't have to enter connection properties again. Also filters can be effectively used to provision required set of users ( ex. idds.group.filter )

2. Proxy mode

Spoiler (Highlight to read)Here, the SAP Identity Directory acts as a proxy connector.Here, the SAP Identity Directory acts as a proxy connector.

To utilize SAP Identity Directory as a SCIM 2.0 based proxy connector, follow these steps:

  1. Create a System User:
    1. In Cloud Identity Services, create a system user under the Administrator menu.
    2. Note down the credentials (certificate-based authentication is also an option).
  2. Configure SAP Identity Directory as a Proxy System:
    1. Add SAP Identity Directory as a proxy system in identity provisioning.
  3. Optional: Define Transformation Logics:
    1. If needed, write transformation logics (remember that not all SCIM attributes support filtering).
  4. Connect External System via SCIM Protocol:
    1. Establish a connection between the external system and Identity Provisioning for managing users and groups.

For further details, refer to the SAP documentation

3. Merging attributes

Spoiler (Highlight to read)Read attributes of a single user from multiple source systems and merge the same in SAP Identity DirectoryRead attributes of a single user from multiple source systems and merge the same in SAP Identity Directory

If an identity requires the aggregation of personal or technical data from various systems, SAP Identity Directory can be leveraged to consolidate data from multiple source systems.

There are two supported methods for achieving this: PUT and PATCH.

PUT: This method involves updating the entire identity data, which includes both existing and new attributes. It reads the complete identity data before provisioning any changes.
PATCH: The benefit of using PATCH is that it provisions only the new attributes of an identity, bypassing the need to read the entire identity data. This approach is more efficient when dealing with merging scenarios.
Important Note: When merging data, adhere to SAP’s design recommendation by using provisioning jobs for one system at a time. This practice helps prevent potential data loss.

For further details on these merging properties, please refer to the SAP documentation here.

4. Connector support for Additional schema attributes

The SailPoint Local Identity Directory Connector provides robust support for both custom attributes and CIS user schema extended attributes. Below is a detailed explanation of how to implement and utilize these features.

4.1 Custom Attributes

Custom attributes in the CIS are designated with labels such as customAttribute1, customAttribute2, up to customAttribute10. To support these attributes, follow these steps:

  1. Add New Account Schema Attribute:
    • Create a new account schema attribute named customAttribute1.
  2. Operations Supported:
    • The connector enable both aggregation and provisioning operations for these custom attributes.

4.2 Extended Schema Attributes

Extended schema attributes can be incorporated using jsonPathMapping. For example, to support the extended attribute SpExt1 under the schema urn:pag:cloud:scim:schemas:extension:spint:2.0:User, include the following jsonPathMapping key in the source XML:

<entry key="jsonPathMapping">
<value>
<Map>
<entry key="SpExt1" value="[&apos;urn:pag:cloud:scim:schemas:extension:spint:2.0:User&apos;].SpExt1"/>
</Map>
</value>
</entry>

Connector Schema Attributes

After defining the jsonPathMapping, add the connector schema attributes as follows:

<AttributeDefinition internalName="SpExt1" name="SpExt1" type="string">

<Description>SailPoint Demo extended attribute</Description>

</AttributeDefinition>

Important Note

Please be aware that the above generic support relies on the capabilities of the SAP Local Identity GA API.

Related Content

SAP Identity DirectoryThe SAP Identity Directory serves as the foundational component for storing user and group information within the SAP Cloud Identity Services infrastructure. It can be configured to acts as the authoritative source for users who need access to SAP cloud applications and functions as the persistence ...