Skip to Content
Technical Articles
Author's profile photo balaji c47

SSO between Success Factors and Azure through IAS

This blog covers the Single Sign-On Configuration between Success Factors and Microsoft Azure AD through Identity Authentication Service. There are numerous notes/materials that you could find in google, but there will not be any configuration guide with a complete scenario. Therefore, this blog will you help out with end-end configurations of Single Sign-On. There are some more add-ons such as the requirements that I had received and the alternative solutions provided.

Before knowing the steps in configurations, we need to know about the pre-requisites.

  • Success Factors BizX
  • Microsoft Azure AD
  • Identity Authentication Service
  • Identity Provisioning Service


Identity Authentication Service and Identity Provisioning Service needs to be procured from the SAP by raising a support incident. IPS will be provisioned to your S-User id, whereas the first administrator created for the IAS tenant receives an activation e-mail with a URL in it. Nevertheless, this was a legacy way of requesting those tenants. SAP has introduced a new way of requesting this Identity Authentication Service through the Upgrade center in Success factors in one of the quarterly release updates. Please refer to the following KBA if you’re a new customer/partner who is implementing SSO. Although, you can refer to steps 7 to 11 from this blog.


The IAS and IPS initial set up was configured by SAP when I have requested those tenants. However, after the release updates, the source and target needed to be set up by ourselves using implementation guides.


Step 1

Create an Administrator account with the type as a system to establish a connection between IAS and IPS.


Step 2

Provision the user id with all the API permission in the success factors.


Step 3

Configure the source and target systems in IPS. The Source system (Success factors) can be configured with a predefined setup or manually. Here I have used the predefined setup JSON file.


For every system supported by the Identity Provisioning service, there is an initial (default) transformation logic that converts the system-specific JSON representation of the entities from/to one common JSON. You can see it on the Transformations tab when you create a new system, after saving it. You can adjust the transformation mapping rules to reflect the current setup of entities from the source or target system.


Properties help you to customize the way your identities read from a source system or provisioned to the target system. They can also filter which entities and attributes to read or skip during the provisioning job. According to their usability, properties can be categorized as:

  • Standard
  • Credential
  • Default
  • Parameterized


The target system (IAS) can similarly be configured with a predefined system setup JSON file or manually.



In the same way, the transformation and properties tab needs to be configured.



Step 4

The Read & Re sync jobs.

  • Read Job – The job reads all entities from the source system and provisions them to the target one. If there are any changes in the target system, they are not affected by the read job. A read job checks only for changes in the source system.
  • Re sync Job – This job reads all users in the source system and overwrites all entities in the target system. If there have been changes in the target system, they are overwritten with the information from the source system. After running a re synchronization job, the entity data in the source and the target system becomes the same.


Step 5

Prerequisite – Success factors metadata file (see Annexure section)

You can create a new application and customize it to comply with your company requirements. Configure a SAML 2.0 service provider (Success factor) in the administration console for SAP Cloud Platform Identity Authentication service. The trust is configured by uploading the service provider metadata, or by entering the information manually. You can enter manually the name of the service provider, its endpoints, and its signing certificate.




Step 6

As a tenant administrator can view and download the tenant SAML 2.0 metadata. You can also change the name format and the certificate used by the identity provider to digitally sign the messages for the applications.

Access the tenant’s administration console for SAP Cloud Platform Identity Authentication service by using the console’s URL. Under Applications and Resources, Choose the Tenant Settings tile. Choose the SAML 2.0 Configuration list item. The SAML 2.0 Configuration page that opens displays the name of the identity provider, its endpoints, and its signing certificate. You can choose between the following options:

○ To download the identity provider’s metadata, press the Download Metadata File button.

○ To change the default-signing certificate, upload the new certificate as a file or insert it as a text, and save your changes.


Step 7

Logon to your provisioning > Single sign-on settings.

Configure the new asserting party with the SAML issuer and the metadata of the IDP (IAS). Additionally, configure the SP (SF) login and logout URL.



Step 8

Configure the Microsoft Azure AD based on the below standard guide.


Step 9

Prerequisite – Microsoft Azure AD metadata file

Identity Authentication acts as a proxy to delegate authentication to a corporate identity provider. The authentication starts at the corporate identity provider (IdP), with Identity Authentication being the role of an identity provider proxy. As such, Identity Authentication will act as a SAML 2.0 identity provider to the service provider, and as a SAML 2.0 service provider to the corporate identity provider or providers. Once a user is authenticated at the corporate identity provider, successive authentication requests from the service provider, which use the same corporate identity provider will not be forwarded to it while the session at Identity Authentication is active. Identity Authentication will issue assertions based on the user data received during the first authentication.






Step 10

You can choose between a local identity provider and a corporate identity provider to be the default identity provider for your application. When a corporate identity provider is chosen as default, Identity Authentication acts as a proxy to delegate authentication to that external corporate identity provider. In this scenario, Identity Authentication acts as a SAML 2.0 identity provider to the service provider (application) and as a service provider to the corporate identity provider. When a user, for example, an employee who exists in the user store of the corporate identity provider tries to access protected resources in the application, he or she is redirected by Identity Authentication to the corporate identity provider. The user logged on after providing the correct corporate credentials.




Step 11

Activate the SSO using tokens. Logon to the provisioning > Single sign-on settings



Our customer’s main requirement is to use both the login methods (SSO/PWD) and to have the same Success factors URL for SSO. However, without using the partial organization SSO concept, we cannot achieve the login method as SSO/PWD. In order to overcome this hurdle, a custom solution was provided.

If you have configured a connection to a corporate user store, users with user records in Identity Authentication also can log on when the Allow Identity Authentication Users Log On option is enabled.



Sample link:


The above link could be used to log in via the Identity Authentication Service. Therefore, Administrators have given this link as a password login method whereas SSO has activated for all the users in Success factors.


Thank you for your time in reading this.


Source system – Success factors

Target system – Identity Authentication Service

Service provider(SP) – Success factors

Identity provider(IDP) – Identity Authentication Service

Corporate identity provider – Microsoft Azure AD


Success factor metadata:

<?xml version="1.0" encoding="UTF-8"?>

<!-- $Id: SPMetadata.xml,v 1.3 2010/07/23 18:42:31 skalangi Exp $ -->

<md:EntityDescriptor entityID="EntityURL/SF_Instance_Name" xmlns:ds="" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<md:SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">









<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ResponseLocation="InstanceURL/saml2/LogoutServiceHTTPRedirectResponse?company=SF_Instance_Name" Location="InstanceURL/saml2/LogoutServiceHTTPRedirect?company=SF_Instance_Name"/>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="InstanceURL/saml2/SAMLAssertionConsumer?company=SF_Instance_Name" index="0"/>



<md:OrganizationName xml:lang="en">SuccessFactors</md:OrganizationName>

<md:OrganizationURL xml:lang="en"></md:OrganizationURL>



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pradeep Kumar Katikere Ningappa .
      Pradeep Kumar Katikere Ningappa .

      Good blog Balaji .

      I think userId concept needs to be changed to personKeyNav.perPersonUuid

      Author's profile photo balaji c47
      balaji c47
      Blog Post Author

      Thank you, Pradeep! personKeyNav is the default value for user attributes.

      Author's profile photo Glauber Rosa
      Glauber Rosa

      The steps referred on this Post are not the ones that SAP advises and the process as SAP has designed, this is referring for the case of a manual integration, which is not needed and not advised at this moment as we have created upgrades to make the process simpler and that also do backend settings that will be used later when other modules that uses IAS be implemented as People Analytics.

      Steps 8, 9 and 10 for the SSO integration between Azure and IAS, would remain on our process, though the remaining steps are in conflict with our current process referred below.

      Please refer to KBA and SAP Help Portal Guide Admin Guide

      Author's profile photo balaji c47
      balaji c47
      Blog Post Author

      Thanks Glauber. I agree with you. SAP has enhanced the way of configuring the SSO between SF & IAS recently. This was the legacy way of doing it.

      Author's profile photo Hernan Ibañez
      Hernan Ibañez

      Glauber Rosa como estas?

      Mi nombre es Hernan Ibañez, trabajo en el área de Desarrollo de Sistemas he conectado SSFF DES con IAS e IPS y en el siguite paso es conectarlo con Azure AD, y por este motivo te quería hacer algún comentario: tendrás algún posteo o link de como hacer esto?. Estuve viendo algunas publicaciones y veo que comentas que lo manual no es recomendado por SAP (asi son todos los instructivos que vi) y quería saber si tiene algún documento que puedas facilitarme para poder avanzar con esto.

      Me puedes una ayuda con esto?

      Author's profile photo balaji c47
      balaji c47
      Blog Post Author

      Hi Hernan Ibañez

      You can completely follow this blog for enabling the SSO between Azure and SF except for the steps for requesting the IAS, IPS tenants and initial setup.

      Author's profile photo Orkun TUERKMEN
      Orkun TUERKMEN

      Assuming the integration setup above is done and IAS is used as proxy to Azure IDP. If and how “Native login to ONB when integrated with IAS/IPS to Azure AD” could be done?

      Author's profile photo balaji c47
      balaji c47
      Blog Post Author

      Hi Orkun TUERKMEN

      I hope this helps -

      Author's profile photo Pavan Srivasta
      Pavan Srivasta

      Good One Balaji..Appreciate your efforts on creating the step by step procedure..!!