Skip to Content
Technical Articles
Author's profile photo Sonia Petrescu

SAP Cloud Identity Services – Why and how to integrate them for a consistent identity lifecycle?

When it comes to the SAP Cloud Identity Services, some of the most common questions raised in implementation projects revolve around: “What would be the best option for us out of all available ones?”. This blog will explain what those options are and how to choose among them. So let’s start from the beginning!

What are the SAP Cloud Identity Services?

The SAP Cloud Identity Services (SCI) are the dedicated cloud services that provide functionalities for authentication & single sign-on and identity lifecycle across SAP solutions. SCI include the Identity Authentication (IAS), Identity Provisioning (IPS), Identity Directory (IdDS) and soon also the Authorization Management services (AMS).

How can I integrate them in my landscape?

Quite often the answer that you get to this question is: “It depends! There are many options depending on your current architecture”. This is true, but just to a certain extend.

The backbone of all recommended IAM landscapes, depicted below in Figure 1  has clear elements:

  • User persistency in the SAP Cloud Identity Services
  • SAP Cloud Identity Services – Identity Provisioning used for user provisioning between the persistency layer inside the SAP Cloud Identity Services and the target applications.


Figure 1 Target Architecture for Identity/User Lifecycle

Currently IPS offers a mechanism to distinguish groups belonging to a specific system based on prefix, for scenarios where authorization (group) persistency is necessary. This topic is out of scope for the current blog post, but it will be dealt with in a future one.

Keeping this in mind, let us look closer at the above architecture and tackle the “it depends” parts. The parts that are customer specific are:

  • how to replicate users and authorizations in the SAP Cloud Identity Services


  • what are the end-to-end provisioning flows

The following chapters explore the differences and offer recommendation for each variation.

1.    User and authorization replication in the SAP Cloud Identity Services

Customer landscapes vary in terms of user source. However, the main categories are:

  • HR integration with SAP Success Factors
  • Integration with an IAM solution

1.1 HR integration with SAP SuccessFactors

The standard integration with SAP SuccessFactors (SAP SFSF) ensures that the active employees will be read from the source system (in this case SAP SuccessFactors) with the Identity Provisioning and written in the persistency layer of the SAP Cloud Identity Services which is the Identity Directory. SAP offers a standard integration that can be triggered from the Upgrade Center of the SAP SFSF.

Figure 2 SAP SuccessFactors integration

When designing an IAM landscape, an important requirement is the possibility to identify a user across systems. For this, one needs a common identifier that acts as a correlation attribute. In the SAP landscape this is the Global User ID and it is generated in SCI by the Identity Directory upon user creation. It can be generated externally, however check that all the SAP applications in scope support this.

By default, in this flow the SCI generated global user ID is written back from the SAP Cloud Identity Services. If your integration contains People Analytics, then the standard integration will take care of the overall flow.

Recommendation: Use the predefined integration flow.

1.2  Integration with an Identity Access Management solution

Since not all setups include SAP SFSF, let’s have a look at the available options for data replication in SCI.

Recommendation: If possible, provision the users from your IAM solution directly to the SAP Cloud Identity Services persistency layer (Identity Directory) – Figure 3. Should your solution lack this capability, use the IPS in the middle to pull this information from your solution and to write it in the Identity Directory – Figure 4.

The next subchapters will list the available options.


Figure 3 Direct Provisioning                                                    Figure 4 Provisioning Flows with IPS


1.2.1      Direct provisioning in the SAP Cloud Identity Services

The most efficient way to import the users from an external source (such as a corporate user store or an IAM solution), is to push them directly into the SCIM API of the SAP Cloud Identity Services.

Check the SAP API Business Hub for details: SAP Cloud Identity Services – Identity Directory.

1.2.2      Provisioning flows with IPS

Besides a direct provisioning, data replication can also be achieved with IPS. The service offers various connectors  that can be used for data reading operations from various source system types. Simply choose the right one for you and as a target system, choose the Identity Authentication. Note that under this connector name, there are two APIs. The switch between them is done via the property ias.api.version. The default value is 2 and it represents the Identity Directory API.

1.2.3      Provisioning flows with IPS in proxy mode

For specific requirements or integrations (ex. with SAP IdM described in subchapter 2.3, or with SAP Identity Access Governance), IPS can be used in proxy mode. Unlike the previous setup where you defined one source system for data reading (the user store/IdM) and one target system for the data writing (in this case the SCI persistency layer), now you will have only one system defined for both read and write operations, that is the proxy system.  Your IdM solution will trigger the reading and writing in/to the proxy system (that is the persistency layer in the SAP Cloud Identity Services).

Generally, one of the reasons for opting for user provisioning with IPS in proxy mode (3rd party IdM) is the requirement that the central IdM solution must know the end-to-end provisioning results. Currently, if this is performed decoupled from IdM, then the end-to-end visibility of provisioning result is not directly available. This is a requirement that will be addressed by future enhancement, so stay tuned for more cool features !

2.    User and authorization replication from the SAP Cloud Identity Services

Once the users and groups are available in SCI, we can replicate them with IPS to target applications. As already mentioned, IPS has dedicated connectors for various SAP target applications, saving your time implementing point to point connection.

Furthermore, SCI offers default integrations for many SAP applications via bundles. The bundles ensure that during your SAP Cloud solution’s order fulfilment process, it is checked whether a customer already has SCI tenants. If not, SCI tenants will be created and pre-configured for out-of-the-box integrations between SAP solutions.The premise for this to work is that the users (and in some cases also groups) persist in SCI.  One such scenario is the integration between SAP SuccessFactors and People Analytics.

For special project requirements, check the real time provisioning capabilities of IPS. This might be what you need for scenarios where SCI self-registered users need immediate system access.

3.    Putting it all together: the end-to-end flow

In the first chapter, we went through options for provisioning in the SAP Cloud Identity Services and in the second one, we understood how to leverage IPS for provision users and groups onwards to the target system. Now let’s bring the pieces together and look at the big picture: the end-to-end scenarios!

The next five sections explain the most common project scenarios and offer a recommendation for each case. The list is by no means exhaustive, but the categories were chosen in such a way, that most of the real-life architectures can be simplified seen as one of them.

3.1  Standard integration with SAP Success Factors and a central Identity Management solution

SAP aims at delivering scenarios that are optimised and preconfigured for various SAP SaaS target applications. The terminology in the official documentation is “bundle tenants” . SAP’s intention is to offer out-of-the box configurations that work by default. The assumption is that the users are persisted in the SAP Cloud Identity Services.


Figure 5 Standard integration with SAP SFSF and a central IdM solution


Recommendation: Leverage the standard connection for user replication to the SAP Cloud Identity Services. Use the IPS for the user/groups provisioning between SCI and the SAP Cloud applications and the Identity Management solution for the on-premise flows.

The IPS connectors are optimised for the SAP cloud applications and are in many cases already pre-configured as part of the SAP bundled scenarios. However, most of the (on-premise) Identity Management solutions offer workflow engines that are optimised for on-premise flows.

Currently, the standard integration between IdM and SAP SFSF assumes that the cloud flow is leading. When the identities are active, they will be replicated to the persistency layer in SAP SCI  and read from there by the IdM solution that will distribute them further to the on-premise systems. If there are attributes that are only maintained by the IdM solution such as the e-mail address, then they will be written in the SAP SFSF system.

An alternative flow could also be adopted, namely if the Identity Management solution is the one leading. This would assume that IdM would read the information from SAP SFSF and transfer it to the Identity Directory.  For this to works, one must also consider that the Global User ID must be written back to SAP SFSF. Also, the integration with People Analytics must be manually reconfigured. Stay tuned for more information on this scenario in a future blog.

3.2  Standard integration with a central 3rd party Identity Management solution

Similar to the previous subchapter, the recommendation is: use IPS for the user/groups provisioning between SCI and the SAP Cloud applications and the Identity Management solution for the on-premise flows.


Figure 6 Standard integration with a central IdM solution

As explained in the chapter above, the identity and authorization provisioning to the SCI persistency layer (the Identity Directory) is performed directly from the central IdM solution.

The central IdM solution is in charge of the correctness and consistency of user data, as well as centrally triggering the creation/ modification and deletion of the identities.

3.3  Standard integration with a central SAP Identity Management solution

The SAP specific integration with a central on-premise solution is the one with the SAP Identity Management – Figure 6. It is standardised and documented on SAP side (IPS Link, SAP IdM Link).

As in with 3rd party solutions, we have two options: to use the connector package  and write the users directly in SAP Cloud Identity services or to use IPS in proxy mode and connect to the IdDS. Note that the standard direct connection uses still the SCIM API V1 that is deprecated, but the Business Extensions from Consulting have an updated version of this connector that leverage the SCIM API V2 – that is the IdDS.

Recommendation: Replicate the users and groups to the SCI direct from SAP IdM. Use the IPS for provisioning between SCI and the SAP Cloud applications and the SAP Identity Management solution for the on-premise flows.

3.4  Integration with a central 3rd party Identity Management solution

Keep in mind that this implementation is not a recommended one. It assumes that the IAM administrator is responsible for creating and above all maintaining, all the point-to-point connections to the target applications. Any changes that might come regarding provisioning to target SAP SaaS applications, could mean extra effort at customer side.


Figure 7 Integration with a central 3rd party IdM solution (not recommended setup)

However, for those implementations where the central IdM solution must control directly all the provisioning flows, the recommendation to replicate the user to the SAP Cloud Identity Services remains valid. This will ensure a proper and integrated functionality for those applications or functionalities that rely on these services such as SAP Task Center or SAP BTP applications that will consume the AMS.

3.5  No IAM automation in place

This scenario is mostly suitable for PoCs or scenarios where there is no central identity management in place.


Figure 8 Cloud-only scenarios

Recommendation: Leverage the standard connection for user replication to the SAP Cloud Identity Services. Use the IPS for the user/groups provisioning between SCI and the SAP Cloud applications as well as the on-premise flows. 

What are my benefits for integrating them in my landscape?

Several SAP integrations revolve around the usage of SAP Cloud Identity Services and their number is expected to increase. Using the services represents more than just a prerequisite because they offer:

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


Additional information




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Todor Petrov
      Todor Petrov

      Hi Sonia,

      thank you for the wonderful blog, I would like to ask you, if you can elaborate a bit more on the following topic:

      "soon also the Authorization Management services (AMS)".

      How soon is soon and what is the scope of the AMS service?



      Author's profile photo Christian Cohrs
      Christian Cohrs

      Hi Todor,

      technically, AMS is already available as part of SAP Cloud Identity and you will find some details in the documentation of Identity Authentication service.

      However, most customers still can't see AMS in the console because it is only visible for business applications that adopt it. Such an application is currently in beta and hopefully generally available soon.

      Best regards,


      Author's profile photo Todor Petrov
      Todor Petrov

      Hi Christian,

      thank you for the quick answer.

      Can you elaborate a bit more on what functionality does this service bring to the table (high-level).

      Thank you,


      Author's profile photo Christian Cohrs
      Christian Cohrs

      Hi Todor,


      thanks for your interest! We will do a proper roll-out soon.


      Best regards,


      Author's profile photo Michael Shea
      Michael Shea

      We do have a release note that teases this function as far as it is needed for the application Christian mentions.

      As Christian mentioned, there will be more roll-out soon.

      Author's profile photo Gregor Wolf
      Gregor Wolf

      HI Michael,

      thank you for sharing the related What's New entry. Based on that there is also a link to the documentation Configuring Authorization Policies. Unfortunately right now quite general. Please keep us posted how we as developers can define authorization policies.

      Best Regards

      Author's profile photo Stefan Ressing
      Stefan Ressing


      great overview, is the IAS renamed to the Identity Directory?


      Many of my customers have used the IAS as Proxy to their Azure AD etc. I would be great to draw an architecture like this too. They like the idea that the IAS is the single connection to SAP Cloud Apps but the user store is in Azure AD.



      Author's profile photo Michael Shea
      Michael Shea

      Identity Authentication isn't being renamed, but rather SAP Cloud Identity services has been gaining capabilities, in addition to authentication, we have the examples of the directory user data and authorization capabilities.

      Author's profile photo Carsten Olt
      Carsten Olt

      Hello Sonia,
      two additional questions concerning your blog.

      First about SCIM API versions 1 and 2. It says version 1 is deprecated, hence still usable. Is there a deadline for this, i.e. will SAP give a specific point in time from which version 2 must be used? Unfortunately, there are no concrete statements about this and this is an often-asked question.

      In addition, we have made a good experience in connecting SAP IDM 8.0 to the IdDS (IAS user store) using the SCIM 2.0 connector (SCIM Connector Package) via an IPS proxy system. It works fine incl. the mapping of many fields like cost center; manager Id; Department; company related and custom Attributes. This way Identity Provisioning acts as a proxy between SAP Identity Management and the cloud system (here IAS).

      In your blog, you addressed the two options via the old connector ( or the "newer" one from the RDS and you recommend provisioning the users directly in SCI. Even with this connector, are there decisive advantages here compared to the IPS proxy system and the normal SCIM 2.0 connector that also uses the SCIM API 2.0 (IdDS)?

      Many thanks

      Author's profile photo Todor Petrov
      Todor Petrov

      Hi Carsten,

      for your second question, i fully support the way you did the integration. This is the way forward. The connector package in IdM (SCI) is not developed further and therefore makes no sense to use it. As you correctly mentioned, the proxy system connected through SCIM is fulfilling all requirements so far and you are also staying up to date with any updates that IPS may deliver due to change of API or any other improvements in IAS.



      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Todor, great, thanks for confirming that we're on the right track. Cheers Carsten