Recently I have read a very informative SAP Blog Post written by Prodyot Sen, titled ‘Manual Steps to Enable SSO between SF and IAS tenant‘.

I have decided to discover SuccessFactors, authenticated with SAP Cloud Platform Identity Authentication Service (IAS), with provisioning users from SFSF to IAS via SAP Cloud Platform Identity Provisioning service. This scenario is often used among customers, and I believe it’s worth taking a look at the configuration. Come and join my journey!

Prerequisites:

1. You have an active license for SAP Cloud Platform Identity Authentication Service.
2. ‘Manage Applications’ and ‘Manage Corporate Identity Providers’ authorizations are assigned to you as Administrator in IAS.
3. You have a valid S user ID.

We will get a demo SuccessFactors instance and a trial IPS tenant during this tutorial. However, if you have a test/productive SuccessFactors instance and a test/productive IPS tenant, you can use them as well. If you don’t use demo SuccessFactors instance, use the Upgrade Center instead of manual configuration.

Step 1: Get a Free SuccessFactors Instance!

If you have an S user, request a Provisioning Account in one Demo Environment:

Go on https://hcmcloudops.successfactors.com/Implementation/IRequests, and select ‘Restricted Access Request – Demo‘.

A Provisioning Account ID allows you to access the SuccessFactors Business Execution Suite interface to perform configuration. Having this account, we will be able to connect our SFSF to IAS to authenticate.

Completing the ‘Restricted Access Request – Demo form’ to automatically generate a Provisioning account for one of the Demo environments.

You will receive an e-mail with your credentials.

Then initiate a demo instance on the ‘Partner Demo Request Tool‘. The Demo Request Tool streamlines the creation of free trial demo instances for Partners and SAP Employees.

You will receive an e-mail with the following information:

• Company Link
• Company User Name: sfadmin
• Company Password

Finally, go again to https://hcmcloudops.successfactors.com/Implementation/IRequests#, and click on ‘Demo Instance Access Request‘. Complete the required information as you already have a Provisioning Account in the relevant data center on the demo environment and you’d like that Provisioning Account mapped to your existing demo instance.

Note: A demo limit of 2 instances per individual is based on environment capacity. The demo instance will be terminated in 30 days.

Step 2: Create an Application in Your IAS for SuccessFactors!

This step describes the application creation process within your IAS tenant for your SuccessFactors.

1. Open Identity Authentication Service (IAS) Admin Console: https://<tenantid>.accounts.ondemand.com/admin
2. Navigate to ‘Applications & Resources’ tile. Click on ‘Applications’.
3. Create a new application by clicking the ‘+ Add’ button on the bottom of the page.

In this example, I have named the application: ‘SFSF’.

Modifications:

1. Change the ‘Subject Name Identifier’ to ‘Login Name‘.
2. Change the ‘Default Name ID Format’ to ‘Unspecified‘.

Add ‘Login Name‘ attribute to the ‘Assertion Attributes’ section: map ‘Login Name’ to ‘loginName‘:

Turn on ‘Login Name’, as allowed logon alias: choose ‘Applications & Resources’ → ‘Tenant Settings’ → ‘Logon Alias’ -> turn ‘Login Name‘ ‘ON’:

It’s time to do the SAML 2.0 configuration!

SAML 2.0 Configuration

At this point, we would need the metadata of SuccessFactors to import, but as we have a demo instance, this point is quite tricky.

I have followed KBA 2747798 – [SSO] Creating the Metadata File for SSO Between SuccessFactors and Identity Provider.

I have chosen DC4 for my SFSF instance, so I will use https://salesdemo4.successfactors.com as InstanceURL.

Maintain the values for SAML 2.0 Configuration manually instead of import.

Values for IAS SAML 2.0 Configuration:

Name: <EntityURL>/<company_id>

For me it is https://www.successfactors.com/<company_id>

Assertion Consumer Service Endpoint: <InstanceURL>/saml2/SAMLAssertionConsumer?company=<company_id>

For me: https://salesdemo4.successfactors.com/saml2/SAMLAssertionConsumer?company=<company_id>

Make sure you make it as ‘Default‘!

Single Logout Endpoint:

HTTP-Redirect binding:

URL: <InstanceURL>/saml2/LogoutServiceHTTPRedirect?company=<company_id>

For me: https://salesdemo4.successfactors.com/saml2/LogoutServiceHTTPRedirect?company=<company_id>

Response URL: <InstanceURL>/saml2/LogoutServiceHTTPRedirectResponse?company=<company_id>

For me: https://salesdemo4.successfactors.com/saml2/LogoutServiceHTTPRedirectResponse?company=<company_id>

HTTP-POST binding: <InstanceURL>/saml2/SAMLAssertionConsumer?company=<company_id>

For me:  https://salesdemo4.successfactors.com/saml2/SAMLAssertionConsumer?company=<company_id>

Use the following as Signing Certificate (taken from the KBA above):

-----BEGIN CERTIFICATE-----
MIICDTCCAXagAwIBAgIETAl/KDANBgkqhkiG9w0BAQUFADBLMQswCQYDVQQGEwJVUzEbMBkGA1UEChMSU3VjY2Vzc2ZhY3RvcnMuY29tMQwwCgYDVQQLEwNPcHMxETAPBgNVBAMTCFNGIEFkbWluMB4XDTEwMDYwNDIyMzMxMloXDTI1MDYwMjIyMzMxMlowSzELMAkGA1UEBhMCVVMxGzAZBgNVBAoTElN1Y2Nlc3NmYWN0b3JzLmNvbTEMMAoGA1UECxMDT3BzMREwDwYDVQQDEwhTRiBBZG1pbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkS3xlwL9v/5kHmfnW0fy2JzIDvHKK4TmkZYHN+JHBLRRzNtlGo1f4yUseMjVn4RF1W11uEqnBySokXv5FYoPd1guJ1Xt3u2Xnj52l/lG4S7ichsPwF3ddDk+pWbKF29Ixt0iBN+keknSRyNGdh9jtOekCg6xq4i4YndwKCucABUCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBzhTmtBbnXpT1aTWDa3PRUx8fWTx/oPjL7xP+WeoTJZmeY4N1c6Q3aZ+u+MhxvmhyDTGo43pyyFVBQjiFzrZUEAAPUrLr7M0e4kGULhxE1p2jnBNfzmVYK397+QPHD2kN/BIzVcMBFsrS+fpdDGWnzj1hjuGLNO/XuPO9eSBRkZA==
-----END CERTIFICATE-----

The digest algorithm for signing outgoing messages: SHA-1.

You will have a similar settings finally:

Step 3: Get a Free IPS Instance!

Neo Trial Discontinuation

SAP will move the focus of our SAP Cloud Platform trial offering completely to the SAP Cloud Platform, multi-cloud foundation (Cloud Foundry environment) and close the trial for the SAP Cloud Platform, Neo environment on November 13th, 2020. We recommend that you log on to your trial account and save any data and applications.

Go to https://cockpit.hanatrial.ondemand.com/cockpit, and scroll down to the bottom of the page: select ‘Access NEO Trial‘.

Choose ‘Services‘ → ‘Identity Provisioning‘. Select ‘Go to Service‘ to open your trial IPS tenant.

Now we will add SuccessFactors as the source system, and IAS as the target system, so that the demo users existing in SuccessFactors will be provisioned to IAS.

Caution: Do NOT use your productive IAS tenant. As there is no demo/trial IAS tenant provided by SAP, you can only use your test tenant for test purposes. The users in SuccessFactors (more than 1200) are dummy users, and performing the below actions they will be provisioned to the IAS tenant’s userbase. If you have a productive SuccessFactors tenant, you can use this tutorial as an example.

Source System

Choose Source Systems, and click on ‘+ Add‘. Select Type: SAP SuccessFactors, and provide a descriptive system name.

The system automatically creates the default properties.

We will now need a technical user userID from the SAP SuccessFactors. We can create a new one, or use one existing one from the Demo SuccessFactors userbase. I will use the second option.

Use the following information got from e-mail to login to your SuccessFactors instance:

• Company Link
• Company User Name: sfadmin
• Company Password

SuccessFactors technical user

I will use the user ‘sfapi‘ as a technical user.

On SuccessFactors, go on ‘Reset User Passwords‘, search for user sfapi, and provide a password for this user:

To do so, click on the ‘Reset User Password‘ button. (More info: KBA 2914191 – [LGN0013]Authentication failed. We have prevented an attempted login from unauthorized ip – IPS job error)

Add an exception in the ‘Admin Center’ → search for ‘Password & Login Policy Settings’ → ‘Set API Login Exceptions‘.

As username, select your API user (for me sfapi), and maximum password age, define ‘-1‘, and select the IP ranges of the IPS tenant you are using. Example: See Neo regions. Then click on ‘Save & Close‘. Note: you need to convert the CIDR notation format for IP range format. You can use 3rd party tool, like http://jodies.de/ipcalc)

We need to have admin permission to access OData API. Create a new group inside ‘Manage permission groups‘. I will use ‘api_group’.

Assign the API user to this group, inside ‘Manage permission groups‘, ‘Group Assignments‘, ‘Assign Employees to Group’:

Create the new permission setting at ‘Admin Center’ > ‘Manage Permission Roles‘ > ‘Manage Integration Tools’ > Enable ‘Allow Admin to Access OData API through Basic Authentication‘. For more information, visit https://help.sap.com/viewer/0377d826832f445e82d09fdac7228f34/latest/en-US/650350ce2e274ee5b1f19c8cb3b1531d.html.

Assign ‘Allow Admin to Access OData API through Basic Authentication’ permission for the newly created group:

Click on ‘Done‘, and grant this role to the API user. Finally, click on ‘Save Changes‘ to save this setting.

Now on IPS, on your source system, go to the ‘Properties‘ tab. I have configured the following properties. More details about these properties can be found on our official SAP Help page.

Type: HTTP”
sf.user.filter: status in ‘t’,’f’,’T’,’F’,’e’,’d’
User: <technical_user>@<company_id>
Password: <password>
Authentication: BasicAuthentication
sf.user.attributes: userId,username,status,email,lastName,firstName,lastModifiedDateTime,personKeyNav
sf.user.attributes.expand: personKeyNav
ProxyType: Internet
ips.trace.failed.entity.content: true
URL: Choose it according to KBA 2215682 – Successfactors API URLs for different Data Centers. For me it is https://apisalesdemo4.successfactors.com/odata/v2.

Target system

Create a new target system in your IPS. Choose Target Systems, and click on ‘+ Add‘. Select Type: ‘SAP Cloud Platform Identity Authentication’, and provide a descriptive system name. As a source system, define the previously created SAP SuccessFactors system. The system automatically creates the default properties.

IAS technical user

On IPS, on the newly created target system, go to the ‘Properties‘ tab. I have configured the following properties. More details about these properties can be found on our official SAP Help page.

ips.failed.request.retry.attempts: 2
Type: HTTP
User: <client ID>
Password: <client ID’s password>
scim.user.unique.attribute: userName
ips.delete.existedbefore.entities: true
Authentication: BasicAuthentication
ProxyType: Internet
ips.failed.request.retry.attempts.interval: 60
ips.trace.failed.entity.content: true
URL: https://<tenantid>.accounts.ondemand.com

Edit the default source system transformation

I will edit the default system transformation: in the Demo SuccessFactors there are users with ‘Business e-mail’, but there are other users without it. I will modify the transformation so that users with the business e-mail will have this e-mail address in IAS, and the others, without business e-mail, will be created with dummy e-mails in the following format <userId>@noemail.com.

So I change:

{
"sourcePath": "$.email",
"optional": true,
"targetPath": "$.emails[0].value",
"correlationAttribute": true
},

to:

{
"sourcePath": "$.email",
"optional": true,
"targetVariable": "emails_temp",
"defaultValue": "NO_EMAIL"
},
{
"condition": "('${emails_temp}' == 'NO_EMAIL')",
"sourcePath": "$.userId",
"targetVariable": "emails_temp",
"functions": [
{
"function": "concatString",
"suffix": "@noemail.com"
}
]
},
{
"sourceVariable": "emails_temp",
"optional": true,
"targetPath": "$.emails[0].value",
"correlationAttribute": true
},

Edit the default target system transformation

I will edit the default target system (IAS) transformation: With the change, all passwords will be written by default in the Identity Authentication. All provisioned users will therefore be able to successfully log in. As the users have dummy emails, I will set the default password ‘Password1’ for all of the users.

Change:

{
"constant": "disabled",
"targetPath": "$.passwordStatus",
"scope": "createEntity"
},
{
"constant": "39",
"targetPath": "$.sourceSystem",
"scope": "createEntity"
},
{
"constant": "employee",
"targetPath": "$.userType"
},

To:

{
    "constant": "initial",
    "targetPath": "$.passwordStatus",
    "scope": "createEntity"
},
{
    "constant": "Password1",
    "targetPath": "$.password",
    "scope": "createEntity"
},
{
    "constant": "employee",
    "targetPath": "$.userType"
},

/* Remove this mapping:
{
    "constant": "39",
    "targetPath": "$.sourceSystem",
    "scope": "createEntity"
}, */

We are doing this configuration based on this Guided Answers. For more scenarios, you can refer to this document as well.

Step 4: Provision Users from SuccessFactors to IAS

Caution: Do NOT use your productive IAS tenant. As there is no demo/trial IAS tenant provided by SAP, you can only use your test tenant for test purposes. The users in SuccessFactors (more than 1200) are dummy users, and performing the below actions they will be provisioned to the IAS tenant’s userbase. If you have a productive SuccessFactors tenant, you can use this tutorial as an example.

On your IPS tenant, go to your Source System, then select ‘Jobs‘ tile, and at ‘Read Job‘, select ‘Run Now‘ action.

Note: this action will provision users from SuccessFactors into IAS.

To check the statistic for the job, open the ‘Job Execution Logs‘. If you click on it, you will see the ‘Job Execution Details‘.

Note: You cannot provision more than 50 entities while the IPS account is of type trial.

We can see, that 50 users were read:

This can be double-checked in the target IAS tenant: go to ‘Admin Console’ → ‘Users & Authorizations’ → ‘User Management‘:

Step 5: Enable SSO between IAS and SuccessFactors

Finally, it’s time to enable SSO between SuccessFactors and IAS. To do so, we will need our SuccessFactors Provisioning Account created at the very beginning of this tutorial.

Open your SuccessFactors Provisioning Account, and select your company. Under ‘Edit Company Settings‘ select ‘Single Sign-On (SSO) Settings‘.

Scroll down until you can see ‘For SAML based SSO‘, then select ‘SAML v2 SSO‘.

Fill in the followings:

SAML Asserting Party Name: name it like you want

SAML Issuer: To get the URL, open IAS Admin Console: https://<tenantid>.accounts.ondemand.com/admin, and navigate to ‘Tenant Settings’ tile. Click on ‘SAML2.0 Configuration’. Copy the value of the ‘Name’ field.

Require Mandatory Signature: Assertion

Enable SAML Flag: Enabled

Login Request Signature(SF Generated/SP/RP): No

SAML Profile: Browser/Post Profile

Enforce Certificate Valid Period: Yes

SAML Verifying Certificate: Copy it from your IAS tenant: open IAS Admin Console: https://<tenantid>.accounts.ondemand.com/admin, and navigate to ‘Tenant Settings’ tile. Click on ‘SAML2.0 Configuration’. Copy the value of the ‘Signing Certificate’ field between
—–BEGIN CERTIFICATE—–
and
—–END CERTIFICATE—–

You will see something like this:

For the ‘SAML v2 : SP-initiated logout‘ settings, provide the followings:

Support SP-initiated Global Logout: Yes

SP sign LogoutRequest: Yes

SP validate LogoutResponse: No

Global Logout Service URL (LogoutRequest destination): Copy the value from your IAS tenant: open IAS Admin Console: https://<tenantid>.accounts.ondemand.com/admin, and navigate to ‘Tenant Settings’ tile. Click on ‘SAML2.0 Configuration’. Copy the value of the ‘Single Logout Endpoint’.

Define the ‘SAML v2: NameID Setting‘:

Require sp must encrypt all NameID elements: No

NameID Format: unspecified

SAML v2 : SP-initiated login:

Enable sp initiated login (AuthnRequest): Yes

Default issuer: Selected

single sign on redirect service location (to be provided by idp): Copy the value from your IAS tenant: open IAS Admin Console: https://<tenantid>.accounts.ondemand.com/admin, and navigate to ‘Tenant Settings’ tile. Click on ‘SAML2.0 Configuration’. Copy the value of the ‘Single Sign-On Endpoint’.

Send request as Company-Wide issuer: Yes

SAML v2: SAP IAS integration: Selected

Scroll up until ‘SAML Asserting Parties(IdP)’, and click on ‘Add an asserint party‘ button.

The page reloads, select the newly created party from the dropdown:

Scroll up to the beginning of the page and click on ‘Save’ at the top right section of the screen.

Finally, put any number in the ‘Reset Token’ field under ‘Single Sign On Features’ section. If you click on ‘Save Token’, the SSO will be enabled through your IAS. Token-based login is On.

Step 6: Test SSO with a User Provisioned Through IPS

As we know an example user, swang, we will test SSO with this user.

Under IAS, I can see that user ‘Scott Wang’ has been created.

Open an incognito mode, before you have enabled SAML tracer, as per KBA 2461862 – Collecting SAML traces with Chrome or Firefox. Note: you can enable SAML tracer in incognito mode: menu → More tools → Extensions → select the Details for SAML Chrome Panel → scroll down and enable Allow in incognito.

Open your SuccessFactors instance:

<InstanceURL>/login?company=<company_id>&loginMethod=SSO

For me: https://salesdemo4.successfactors.com/login?company=<company_id>&loginMethod=SSO

We can see, that instead of the SuccessFactors login page, IAS login screen is appearing.

Provide ‘swang’ as the user name and the previously provided password for this user. The user will be prompted to change her password:

After changing the password, the user will be logged in to SuccessFactors via SSO:

From the SAML trace, we can see, that the nameid format is unspecified, and users logged in through IAS using the Login Name.

Summary

I hope I could explain in this tutorial how SSO with provisioned users works between SuccessFactors and IAS. Of course, there are more possibilities to customize the scenario, I wanted to show you a working scenario example what can be useful later if you will implement the above to a productive SuccessFactors instance.

Instead of IAS’ userbase, you can use a corporate identity provider, so that IAS will act as a proxy. Once the connection between your IdP and the SAP Cloud Platform Identity Authentication Service is done, you can simply use it to connect it SuccessFactors. You can check my previous SAP Blog Post ‘Connect Okta to SAP Cloud Platform Identity Authentication Service‘ as a reference with Okta IdP.

The following materials are advised to be used for troubleshooting:

If you are facing issues during IAS configuration or SSO, you can download the Troubleshooting logs from your IAS tenant to self-investigate the root cause of the issue. See KBA 2942816 – How to export troubleshooting logs from Identity Authentication Service.

Use the Support Log Assistant to analyze the troubleshooting log automatically. See more KBA 2838708 – Using the Support Log Assistant to automate support-related file analysis. The Support Log Assistant standalone, self-service tool is available here.

Also, we advise checking the IAS Guided Answers about the most common issues: KBA 2701851 – SAP Cloud Platform Identity Authentication Service (IAS) – Guided Answers.

Regarding IPS, use IPS Guided Answers: KBA 2701901 – SAP Cloud Platform Identity Provisioning Service (IPS): Guided Answers – Guided Answers.

Use the Support Log Assistant to analyze the job log automatically. See more KBA 2838708 – Using the Support Log Assistant to automate support-related file analysis. The Support Log Assistant standalone, self-service tool is available here.

For SuccessFactors, use SSO Log Viewer, see KBA 2317944 – SAML 2.0 Provisioning Guide – Troubleshooting Tips and Tricks – Common Errors and Resolutions.

For SuccessFactors metadata, refer to KBA 2707993 – [SSO] Metadata file for SSO | How to generate it for either SF x IDP and Outbound SSO scenarios.

In any other SSO issues, double-check KBA 2954188 – Failing to login to SuccessFactors instance through SAP IAS (Cloud Platform Identity Authentication Service).

Thank you Prodyot Sen, for your inspiring SAP Blog Post ‘Manual Steps to Enable SSO between SF and IAS tenant‘ I could use as a basis for my blog post.