Skip to Content
Technical Articles
Author's profile photo Istvan Bokor

How to authenticate to SuccessFactors with users provisioned by IPS via IAS SSO?

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:

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.

EntityURL InstanceURL
DC2 https://www.successfactors.eu https://salesdemo.successfactors.eu
DC4 https://www.successfactors.com https://salesdemo4.successfactors.com
DC8 https://www.successfactors.com https://pmsalesdemo8.successfactors.com

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

  1. Create a technical user (of type System) with a password and a generated client ID for authentication between the REST API calls and the Identity Authentication tenant. The client ID is in the universally unique identifier (UUID) format and is generated automatically when you set the password for the first time. For more information, see: Add System as Administrator
  2. Assign authorization roles ‘Manage Users’ and ‘Manage Groups’ to the technical user. This way you can create, edit and delete users and groups in the Identity Authentication user store.
You can disable the other authorizations if you want.
Click on ‘Save‘, and select ‘Set Password‘ to define a password for authentication.
After saving this, and going back to ‘Set Password‘, you will see your ‘client ID’.

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.

Assigned Tags

      16 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Lucas Vaccaro
      Lucas Vaccaro

      Great work, Istvan!

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Thank you, Lucas! 🙂

      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Istvan,

      that is a nice blog. I am questioning myself why would a company want that to provision users from SFSF to IAS? In the end, most customers want real SSO experience. They don't want the users to enter a password for accessing SFSF.

      Real SSO is based on the primary authentication that is mostly the AD login and thus TGT. How would that work with IAS connected to Active Directory as an on-premise user store and if SPNEGO is enabled? Why would I need AD and SFSF user profiles in IAS?

      Can you explain the advantages of this approach? I am not an SFSF expert. However, taking common customer requirements into account, I'd rather recommend using a corporate IdP to incorporate authentication for SFSF. MFA or SSO can be configured on-demand. Advantages and Disadvantages, of using IAS as proxy can be found here and here

      Cheers Colt

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Hi Colt,

      Thank you for your inputs.  There are various customer demands.

      As ar as I know (I'm not a SuccessFactors expert), there is this requirement as new features will be integrated using IAS (Embedded Analytics/SAC) and users will need to have an active session on IAS to access those features.

      IAS can be used also as a real SSO, as we are providing authentication via certificates, SPNEGO and IdP initiated SSO.  If you are using a corporate user store, like LDAP, there will be a user, generated in IAS, and the password will come from LDAP, see: "With this initial successful authentication of the user, a partial user record is created in the user store for Identity Authentication. It is created with user details taken from the corporate user store. The cloud user store does not copy the user's credentials. With subsequent logins, the user is always authenticated against the corporate user store, and the user record is updated. Source: SAP Help)".

      IAS can be used as a proxy, so it can be integrated with corporate IdPs, like Azure, Okta, etc. There are unlimited possibilities in IAS, I just highlighted this scenario, as I can see from customer incidents that it is used in a high volume.

      Regards, Istvan

      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Istvan,

      you don’t get my point 🙂 I am not questioning the IAS and aware of its functionality.

      However, in your scenario you use SCIM/IPS to provision users from SFSF (source) to IAS (target) and I was wondering how this would work together with scenarios where you connect your on premise user store (AD) or corporate IDP to SFSF.

      Guess in such situations you would not have to involve IPS to provision users to IAS, instead more likely to provision users to SFSF as a target. SSO to IAS and this way SSO to SFSF based on the SAML NameID mapping is achieved

       

      So what benefits does it bring to provision users from SFSF to IAS - I still don’t see the benefits 🙂

      Cheers Colt

       

      Author's profile photo Sushil Gupta
      Sushil Gupta

      Hi Carsten,

      I also had the same questions. I am sharing my findings on this below:

      There can be multiple scenarios where IAS can be used and User sync is required between SF and IAS – so that we can make use of IAS functionality.

      Example:

      In case we have different Unique identifiers.

      1) Success factors application only supports Username as a unique identifier for SAML2.0 (mostly used for SSO setup) and lets suppose your Corporate-IDP (Azure AD) is using email address as UPN. 

      Different Unique identifiers – User sync is required so that mapping can be done in IAS.(Provides flexibility)

       

      2) In case you have multiple corporate IDPs and you want to setup rules – in conditional authentication.

      Example – For one SF application – you want to authenticate multiple users – (as per their domain) to redirected to different corporate IDPs. User sync is required so that you can perform this.

      Sharing the scenarios when user sync is mandatory – from SAP documentation:

      >>>

      You must sync ALL users to the SAP Cloud Platform Identity Authentication Service before you activate the
      SAP Cloud Platform Identity Authentication service. User sync is critical when using the following services
      and features:

      ○ Conditional Authentication: To set up with rules that authenticate based on email, user type, or group.
      ○ People Analytics, Internal Career Site, and other SAP SuccessFactors product areas: User
      identifiers can change between product areas and the SAP Cloud Platform Identity Authentication
      Service can only map these identifiers correctly when your users are in SAP Cloud Platform .Identity
      Authentication service.
      ○ Global Assignment & concurrent employment: when users log on from different sources, SAP Cloud
      Platform Identity Authentication service needs to convert their identifiers so that SAP Cloud Platform
      Identity Authentication service understands them. That only happens when user sync has been done
      and the users are loaded into SAP Cloud Platform Identity Authentication service.
      ○ Enablement of Partial SSO: If you intend to user partial sso, your users should exist in SAP Cloud
      Platform Identity Authentication service.
      ○ Two-factor Authentication: Your users need to exist in SAP Cloud Platform Identity Authentication
      service so that you can take advantage of two-factor security features.

      <<<

      In case you don’t sync the users from SF to IAS.

      Functionality supported: IAS – act as proxy –

      1 application connecting to 1 corporate IDP – I think which we can perform directly in SF application.

       

      I think its just depend on – what is the scenario and requirement. Let me know your thoughts on this !

      Thanks and Regards

      Sushil

      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Sushil,

      many thanks, very informative. I will let you know my experience once I had the chance to setup such a project 😉

      Cheers Carsten

      Author's profile photo Murali Shanmugham
      Murali Shanmugham

      Thanks for sharing

      Author's profile photo Sushil Gupta
      Sushil Gupta

      Hi Istvan,

      Very informative blog ! Thanks for sharing it in such detail !

       

      Thanks and Regards

      Sushil K Gupta

      Author's profile photo Pooja Rane
      Pooja Rane

      Thank you so much for the comprehensive blog Istvan! It was really helpful 🙂

      I have one quick question though if you could clarify.

      We will be doing IAS activation (2nd upgrade) soon in QA system. A few weeks back, we had manually disabled the SSO token in Provisioning as customer wanted.

      My question is should we enable the SSO token before starting IAS activation? Will it throw any error during upgrade if the token is kept deactivated?

      Or will IAS activation process automatically enable the token?

      Best Regards,

      Pooja

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Hello,

      I am from the IAS and IPS Support team, upgrade process belongs to the Platform team, but as far as I know, the Upgrade is setting up everything automatically, so if you leave your setting like it is now, no error would be expected.

      Best regards,
      Istvan

      Author's profile photo arun prasath
      arun prasath

      Hi Istvan,

       

      The blog was very informative. I have one question we have IAM as SSO but now we are enabling IAS for Internal Career Site builder in SuccessFactors RMK. Any idea like do we need to enable SSO for SuccessFactors or with IAM we can only enable SSO between RCM and RMK. Do you have any blog or document which has detail where both IAM and IAS can work as SSO at the same time.

       

      Thanks, Arun.

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Hello,

      I'm from IAS and IPS Support, I would recommend you to ask this question on Community for the relevant team: https://answers.sap.com/questions/ask.html

      Best regards,
      István

      Author's profile photo Michael Healy
      Michael Healy

      It’s a pity there is a hard requirement to have IAS for SAP cloud products, this integration would be made much simpler if one could just use the already existing corp IDP without having IAS in the mix for no apparent benefit.

      Author's profile photo Bojun Zhao
      Bojun Zhao

      Istvan Bokor

      Thank you for your blog.

      Could you help us out of the issue "Add users to IAS Groups via IPS"

      It works fine when we add user to IAS groups based on string filed type using the code below.

      -----------------------------------------------------------------------------------------------------------------------------

      Source System

      {
      "sourcePath": "$.empInfo.empWorkPermitNav.results[0].customString1",
      "optional": true,
      "targetPath": "$.usergroup"
      },

      Target System

      {
      "condition": "$.usergroup == 'Infra'",
      "constant": "Infra",
      "targetPath": "$.groups[0].value"
      },
      {
      "condition": "$.usergroup == 'Internet'",
      "constant": "Internet",
      "targetPath": "$.groups[1].value"
      }

      -----------------------------------------------------------------------------------------------------------------------------

      but It doesn't work well when we change the filed type to picklist filed type, it seems like the setting in the source system is not correct.

      -----------------------------------------------------------------------------------------------------------------------------

      Source System

      {
      "sourcePath": "$.empInfo.empWorkPermitNav.customString1Nav.results[0].optionValue",
      "optional": true,
      "targetPath": "$.usergroup"
      },

      Target System

      {
      "condition": "$.usergroup == '11442'",
      "constant": "Infra",
      "targetPath": "$.groups[0].value"
      },
      {
      "condition": "$.usergroup == '11443'",
      "constant": "Internet",
      "targetPath": "$.groups[1].value"
      }

      -----------------------------------------------------------------------------------------------------------------------------
      Thank you in advance

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Hello,

      Please check KBA 391081 - How to provision company ID from SAP SuccessFactors to Identity Authentication which was written by me and I think giving a good example.

      Best regards,
      Istvan