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!
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).
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:
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:
and
The following chapters explore the differences and offer recommendation for each variation.
Customer landscapes vary in terms of user source. However, the main categories are:
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.
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.
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.
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.
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.
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 !
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.
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.
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.
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.
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.
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.
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 com.sap.idm.connector.sci 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.
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.
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.
This scenario is mostly suitable for PoCs or scenarios where there is no central identity management in place.
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.
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:
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
and
- 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 com.sap.idm.connector.sci 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
- What's New for Identity Authentication
- What's New for Identity Provisioning
- SAP Cloud Identity Services Roadmap
- Submitting Improvement Requests
- SAP Community - Identity Services
- SAP Cloud Identity Services
- SAP Cloud Identity Services – Identity Directory
- SAP Managed Tags:
11 Comments
