Technical Articles
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:
- You have an active license for SAP Cloud Platform Identity Authentication Service.
- ‘Manage Applications’ and ‘Manage Corporate Identity Providers’ authorizations are assigned to you as Administrator in IAS.
- 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.
- Open Identity Authentication Service (IAS) Admin Console: https://<tenantid>.accounts.ondemand.com/admin
- Navigate to ‘Applications & Resources’ tile. Click on ‘Applications’.
- 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:
- Change the ‘Subject Name Identifier’ to ‘Login Name‘.
- 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.
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
- 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
- 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.


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.
Great work, Istvan!
Thank you, Lucas! 🙂
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
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
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
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
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
Thanks for sharing
Hi Istvan,
Very informative blog ! Thanks for sharing it in such detail !
Thanks and Regards
Sushil K Gupta
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
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
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.
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
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.
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
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
Thank you for this insightful blog Istvan.
I was wondering can I have some users use the default SF login page (perhaps by using an alternative link) while users that are provisioned to IAS can login with IAS login. I couldn't find any resource that allows me to implement this scenario.