Background on API Security
In the meantime everybody should know that security is one of the most important aspects when it comes to run software in the cloud and that security is never something which is "done". It's a constant process of adjusting the existing security concepts to newest attack vectors and apply state of the art responses to those. This is even more true for integrations and API based communication.
In 2021 a set of new and more secure authentications mechanisms have been released for SAP SuccessFactors OData and SOAP APIs as well as for the corresponding SAP Integration Suite and Boomi connectors. The new authentication mechanism is oAuth2.0 with SAML Bearer Assertion.
Why is oAuth2 with SAML more secure than the existing Basic Authentication used so far? There are two major answers to this questions:
- SAML Assertions as well as the Access Tokens have a short living validity, hence even if they are exposed they can not be used at all or not for long.
- If a secure connector is used, like the SuccessFactors Connector in SAP Integration Suite, there is no point in time where any person would have access to the secret (private key) used to generate the SAML assertion.
Both are not true for Basic Authentication when API users and passwords are being used. Passwords are long living and everybody who knows it can access the system. The same is true for the visibility of the password. In order to configure it in a connector, at least one person has to enter it and is aware of it.
What can you do to make APIs calls more secure?
For a more secure communication oAuth with SAML Bearer Assertion was introduced in SAP SuccessFactors and in the SAP Integration Suite Connector for OData and SOAP APIs. While the two blogs linked before are describing this step by step for SAP Integration Suite, you can find here an example flow and the video below. They demonstrate the configuration in SAP Integration Suite and SAP SuccessFactors.
In addition you will also find there a postman collection demonstrating the oAuth flow in case you do have to call the SAP SuccessFactors APIs from your own code not using SAP Integration Suite. This postman collection is making use of the oauth/idp call which shall not be used in a productive setup but is just used for demonstration reasons to simplify the overall setup. To make this secure in your own code you have to replace this oauth/idp call and generate the SAML assertion by yourself or with the help of a third party SAML generation tool. It is up to you to establish a secure communication to such a tool and to store securely the private keys for signing the SAML assertion. See also this blog and the documentation one help.sap.com to get more insights into how to use a java example program offered by SAP to generate a SAML assertion using opensaml.
Using the above resources helps customers and partners to improve the overall security of integrations running on SAP Integrations Suite when accessing SAP SuccessFactors APIs. Migrating existing integrations from Basic Authentication to oAuth2 based flows should be part of every integration project. Similar additional security measure can be applied to SFTP servers (using certificates instead of user and passwords) and custom code or 3rd party middleware, e.g. Boomi.
You want to learn more? Listen here to our webinar and subscribe for more information!
In case you are a SAP partner or customer you can listen to gerald.reinhard and karthick.chandrasekaran in this webinar to get more information about the migration from Basic Authentication to OAuth 2.0. Slides are available here.
We will share more information in future with our customers and partners through webinars and this customer community blog. As always you can ask your integration related questions in our customer or partner community for "APIs and integrations".
- SAP Managed Tags:
5 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
