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.
Also Read: What is SAP SF EC Certification?
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.
The IAS and IPS that were initial set up was configured by SAP when I have requested those tenants but after the release updates, the source and target needs 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.
https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/sap-hana-cloud-platform-identity-authentication-tutorialStep 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: https://ias-test.accounts.ondemand.com/saml2/idp/sso?sp=https://www.successfactors.com/&idp=https://ias-test.accounts.ondemand.comThe above link could be used to log in via the Identity Authentication Service. Therefore, Administrators have given with this link as a password login method whereas SSO has activated for all the users in Success factors.
Annexure:
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="http://www.w3.org/2000/09/xmldsig#" 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:KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICDTCCAXagAwIBAgIETAl/KDANBgkqhkiG9w0BAQUFADBLMQswCQYDVQQGEwJVUzEbMBkGA1UEChMSU3VjY2Vzc2ZhY3RvcnMuY29tMQwwCgYDVQQLEwNPcHMxETAPBgNVBAMTCFNGIEFkbWluMB4XDTEwMDYwNDIyMzMxMloXDTI1MDYwMjIyMzMxMlowSzELMAkGA1UEBhMCVVMxGzAZBgNVBAoTElN1Y2Nlc3NmYWN0b3JzLmNvbTEMMAoGA1UECxMDT3BzMREwDwYDVQQDEwhTRiBBZG1pbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkS3xlwL9v/5kHmfnW0fy2JzIDvHKK4TmkZYHN+JHBLRRzNtlGo1f4yUseMjVn4RF1W11uEqnBySokXv5FYoPd1guJ1Xt3u2Xnj52l/lG4S7ichsPwF3ddDk+pWbKF29Ixt0iBN+keknSRyNGdh9jtOekCg6xq4i4YndwKCucABUCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBzhTmtBbnXpT1aTWDa3PRUx8fWTx/oPjL7xP+WeoTJZmeY4N1c6Q3aZ+u+MhxvmhyDTGo43pyyFVBQjiFzrZUEAAPUrLr7M0e4kGULhxE1p2jnBNfzmVYK397+QPHD2kN/BIzVcMBFsrS+fpdDGWnzj1hjuGLNO/XuPO9eSBRkZA==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<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:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">SuccessFactors</md:OrganizationName>
<md:OrganizationURL xml:lang="en">http://www.successfactors.com</md:OrganizationURL>
</md:Organization>
</md:EntityDescriptor>
