Best Practice for SAML Offline generator and local keystore with SAP SuccessFactors
Dear SAP community,
In this blog posting we will share with you the best practice for SAML Offline generator and local keystore with SAP SuccessFactors.
SAP SuccessFactors has deprecated Basic Authentication as of B2011 release (2H 2020 announcement: Planned Retirement of HTTP Basic Authentication (SFAPI/ODATA API)).
Please notice that Basic Auth deprecation was postponed until further notice. You can view the updated schedules here = 2H 2020 announcement: Planned Retirement of HTTP Basic Authentication (SFAPI/ODATA API)
SAP SuccessFactors recommends Customers/ SAP SuccessFactors Software Partners to use OAuth2.0 for Data Integrations.
OAuth2.0 authentication mechanism is respected by SFAPI (CompoundEmployee API)/ ODataV2 / ODataV4 APIs in SAP SuccessFactors.
Generic OAuth2 flow:
SAP SuccessFactors uses the terminology for Authorization token as “Assertion” (SAML2.0) and for Access token as “access_token” as followed in the RFC-7522 specification
Please refer to the Authentication Using OAuth 2.0 section in the SAP SuccessFactors HXM Suite OData API: Developer Guide (V2)
There are 3 ways to generate the SAML Assertion:
- (Recommended) Use a third-party IdP that you trust. Refer to the documentation of that IdP for detailed instructions.
- Use the offline tool.
- Use SAP SuccessFactors IdP. Note that the SAML assertion is valid only for 10 minutes in this case.
This blog provides the solution brief on the second option – Generating the SAML Assertion using SAML offline tool in a secure way.
- In this video we have used a local key pair generation software for demonstration purposes, this is only to depict that SAP SuccessFactors can accept public keys from a 3rd party software (SAP does not recommend any specific key pair generation software, the customer IT/Security team must evaluate the tools available in the Enterprise segment and accordingly make the decision).
- The SAML offline tool used in this video is downloaded from SAP KBA 3031657
- While exporting the Private Key from the local key pair generation software, please do not encrypt it.
- For video purposes we have stored the Private key in a folder, SAP recommends that customers store the keys in secure vaults and keep it safe.
- For video purposes, user by the name “KC” is made up, and does not involve any specific integration scenario.
As ODataV2 is the commonly used APIs by SAP SuccessFactors customers, the example is showcased on SFOData.User entity
- Make sure to create Technical user for Data integrations, with only basic user data.
- Make sure the Role Based Permission assigned to the API user covers the intended target population and API permissions in SAP SuccessFactors.
- Key Pair will have an expiration time, generally in years. When the Key Pair expires accordingly make sure to re-register the client application using the new public key.
- SAP SuccessFactors supports both SHA-1 and SHA-2 signing algorithm.
- Please ensure that there are no spaces and no new line characters in the public key, while registering in the Manage OAuth2 client application screen of SAP SuccessFactors.
- SAML Assertion generated using the offline tool, will have expiration assigned in days (This is a parameter in the “SAMLAssertion.properties” file and can be set accordingly as per the Customer IT team policy for expiration).
- Once the SAML Assertion is expired, the respective Customer IT/Security team must regenerate the SAML assertion and share it with the Integration team.
- SAML Assertion is used to refresh the access token.
SAP Recommends to use strong passwords (As per customer IT/Security team requirements) for securing keystore file. In the video for demo purposes a 3 char password has been shown (0 minute 54 seconds)
SAML offline generation has the following advantages:
- Control over the key pair life cycle – As the customer decides the expiration time
- Securing the private key
- SAML expiration time can be controlled as per customer IT/Security team policy
Hope this sample could be helpful for you 🙂
We would like to give the credits for our colleague Karthick Chandrasekaran (SAP SuccessFactors Product Advisory and Partner Success) for this content.
Just a comment, we have one KBA related to this topic with fix open for 2H 2021 release regarding SFAPI + OAuth. Please check this link = 3080189 - SFAPI + OAuth with error Authentication failed, no API login permission(status code = 14) - SAP ONE Support Launchpad
Just a comment, the 2H 2021 code arrived in preview and this was fixed in preview instances. After November 2021, post 2H 2021 in production instances, the KBA will be archived.
Hi Soliman/Karthick Chandrasekaran,
If you can share the detailed considerations from maven application side(POM etc.), that'd add more clarity.
Dear Annapureddy Dolendra Anan Padman Reddy
The details we have about the apache maven are inside this KBA 3031657 - How to generate SAML assertion for SAP SuccessFactors API using SAP provided offline tool?
Inside this KBA, you can also find the file needed named = "SAMLAssertionGen-master.zip" under attachments.
The KBA steps provided for Windows Operating system. If you are using any other OS, please follow the guidelines provided Installing Apache Maven.
Hope this can help you 🙂
Hi Soliman/Karthick Chandrasekaran,
Is there any working example of generating SAML assertion token locally and then fetching data from API using Python.
So the generator tool seems to be currently unavailable at the link provided in the documentation (see image below) is there anywhere else I can get it or any other similar tools you can recommend?
Hi Pablo, the KBA should be available now, it was being reviewed
Thanks for your reply, now the file appears to have been removed, did reviewing it generate a new url and if so could I have it? Doesn't seem to have been updated in the docs.
Hi Pablo, the attachment should also be available and the URL remains the same, can you check again (try incognito and/or clear the cache first, etc.), thank you!
First of all, thanks for the blog you created.
But I like to ask about the 3rd option you mentioned (or even the 1st option in case of a 3rd party IdP). How do you go about this ? Is this a typical SSO scenario wherein you exchange XML metadata and "api user" authenticates against the IdP at runtime ?
Appreciate your response on this.