Symptom
We are planning to delete SHA1 signing mechanism for SAML exchange between BizX generic IdP and downstream applications with SHA-256 for better security by end of 2024
Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.
What is Involved
There are Assertion Consumer Service entries in customer provisioning setting and each is meant for the integration with a downstream application (internal/partner/third party). This mechanism that is still using SHA-1 should be changed to SHA-256 immediately.
Towards this, we have introduced Application Name (for better identification) and a flag to indicate whether the integration is using SHA-256 signing mechanism. If the flag is not checked, then by default SHA-1 is used. In addition, we have provided a link to download SuccessFactors IdP metadata for SHA-256. The URL is in the format: https://<DC_URL>/idp/samlmetadata?company=<company_id>&cert=sha2 , however will get the certificate in SHA-256 with or without this parameter in the URL and customer's can now download the certificate, and update or delete existing ACS entries from Admin Center-> Authorized SP Assertion Consumer Service Settings page, in addition to under Provisioning. Also when they create a new ACS entry, SHA-256 Certificate flag is by default checked and can not be unchecked.
Provisioning-> Authorized SP Assertion Consumer Service Settings
Admin Center-> Authorized SP Assertion Consumer Service Settings page
Note: The downloaded SHA-256 metadata content will not necessarily have the algorithm mentioned, that is not an issue.
Environment
SAP SuccessFactors HCM Suite
Cause
The migration is being executed to improve the Security on integrations with our SuccessFactors HCM Suite
Resolution
All customers are required to take immediate action over their 3rd party outbound SSO integrations to do the proper updates before November 2024 as we will be deleting code to support SHA1 algorithm. Any ACS entries still using SHA1 will stop functioning after November 2024.
Migration Steps
SAP SuccessFactors internal applications
The integrations belonging internal SAP SuccessFactors applications: SAP Jam, SAP WorkZone, Onboarding 1.0 and Recruiting Posting:
- New integrations: Since July 23, 2021 all new integrations are as default using SHA-256 (No action required and no end user impact)
- Existing integrations: Will be made compliant with the switch to SHA-256, by the end of SHA-1 support. (No action required and no end user impact)
NOTE: Any remaining "demo.sapjam" assertion consumer service URL will not be migrated to SHA-256, as the demo-type JAM tenants no longer exist. If there are any remaining URLs, they can be removed.
SAP SuccessFactors Suite integrations for Learning and Workforce Analytics:
- New integrations: Will be defaulted to use SHA-256 signing mechanism after the Second Half Release 2021. (No action required and no end user impact)
- Existing integrations: Will be migrated post Second Half Release 2021. (No action required and no end user impact)
SAP SuccessFactors Suite integrations to Employee Central Payroll:
-
New integrations: Since July 23, 2021 all new integrations are as default using SHA-256 (No action required and no end user impact)
-
Existing integrations: The customers/integration partners should migrate the existing integrations to use SHA-256 as a self-service upgrade. For this you need to follow the steps in KBA 3046849 - One Time Migration from SHA-1 to SHA-256 of SAML configurations between SuccessFactors IdP and ECP - SAP for Me
Integrations which use SAP Business Technology Platform (formerly SAP Cloud Platform):
- New integrations: should be done using SHA-256 signing mechanism. This option is available now for new integrations and your implementation partner should integrate using the SHA-256 already.
- (Action Required) For SAP BTP, Cloud Foundry and Kyma environment, customers and integration partners have to manual setup Assertion Consumer Service configurations. You can refer to this page to do the setting Configure Single-Sign On Between a Subaccount in SAP BTP and SAP SuccessFactors.
- (No Action Required) For SAP BTP, Neo environment, the Assertion Consumer Service configurations are done automatically using console client commands or MTA. For new integrations, the SHA-256 signing mechanism will be included when using the commands and MTA. You don’t have to do anything additionally. See Register the Extension Application as an Authorized Assertion Consumer Service.
- Existing integrations: The customers/integration partners should migrate the existing integrations to use SHA-256 as a self-service upgrade. For this you need to follow the below:
- For customer with Implementation Partner with provisioning access: Your partner should follow the steps in the follow the below:
- (Action Required) For SAP BTP, Cloud Foundry and Kyma environment, customers and integration partners have to manual setup Assertion Consumer Service configurations. You can refer to this page to do the setting Configure Single-Sign On Between a Subaccount in SAP BTP and SAP SuccessFactors.
- (No Action Required) For SAP BTP, Neo environment, the Assertion Consumer Service configurations are done automatically using console client commands or MTA. For new integrations, the SHA-256 signing mechanism will be included when using the commands and MTA. You don’t have to do anything additionally. See Register the Extension Application as an Authorized Assertion Consumer Service.
- If you do not have provisioning access: You can update SF side as referred on session below and do the update on SAP BTP side at the same time.
- For customer with Implementation Partner with provisioning access: Your partner should follow the steps in the follow the below:
Partner and Third Party Applications
- New Integrations: All new integrations should be done using SHA-256.
- Existing integrations: You will need to migrate by Nov 2024 . To execute the change, you have the below options:
- Engage with a Partner to do the changes for you: Your partner can do the switch following the bellow approaches depending on your 3rd party application;
- Customers do the changes through self-service tool:
- Change SuccessFactors (BizX) side: (both SF and 3rd party sides should be done at same time to reduce integration down time)
- Login to your SuccessFactors instance with an admin with permission Manage System Properties -> Company System and Logo Settings.
- User needs the above permission to access self-service tool Authorized SP Assertion Consumer Service Settings
- Go to Admin Center -> Authorized SP Assertion Consumer Service Settings;
- In the tool, find the right entry with ACS URL matching your third party application ACS URL;
- Check the SHA256 checkbox and select the proper application name;
- Click on Download SuccessFactors IdP Metadata with SHA-256 Certificate to download the metadata with the new certificate for the integration on the 3rd party application.
- Login to your SuccessFactors instance with an admin with permission Manage System Properties -> Company System and Logo Settings.
- Change 3rd Party Application side: (both SF and 3rd party sides should be done at same time to reduce integration down time)
- This change is done on the 3rd Party application side;
- You implementation partner, your service provider or your 3rd party application admin needs to provide how to change the signing algorithm in case you are not aware;
- As for each signing algorithm SuccessFactors will use a different certificate, you will need to update the certificate on the application on their end, below are the links to obtain our certificates.
- The SHA-256 certificate can was downloaded on step 5 above;
- You can also download it from URL https://<SF host>/idp/samlmetadata?company=<companyId>&cert=sha2
- The SHA-256 certificate can was downloaded on step 5 above;
- On your application, you should update the singing algorithm selection as described below, but must be provided by the application provider:
Update to keep Signing algorithm configuration on both side
In this case the assumption is that the third party application keeps a local instance based flag to identify if the instance is using SHA1 or SHA256.
2. Change settings on third party application side to use SHA256
- Third party application should use new certificate for SHA-256 instance to verify the SAML response. The SHA256 certificate can be downloaded from https://<SF host>/idp/samlmetadata?company=<companyId>&cert=sha2
NOTE: The Entity ID URL in metadata will not change after Common Super Domain (CSD) migration. It will remain the same.
See Also
Keywords
SHA256 Outbound SSO SF-IDP SuccessFactors native IdP , KBA , LOD-SF-PLT-PRV , Provisioning Changes , LOD-SF-PLT-SAM , SAML SSO First Time Setup , LOD-SF-PLT-SEL , SSO Errors & Logs , LOD-SF-JAM-INT , Integration with SF BizX , LOD-SF-LMS-INT , Integrations with BizX , LOD-SF-RNR-INT , Vendor Integrations, Integration Center , LOD-SF-VRP-INT , Integrations with CMP, PM, EC, etc. , LOD-SF-CMP-INT , Integrations & Intelligent Services EC , How To
Product
Attachments
Pasted image.jpg |
Pasted image.jpg |
Pasted image.png |
Pasted image.png |