This article is focusing on the authentication options within SAP Cloud Integration (as part of SAP Integration Suite for the Cloud Foundry deployment option).
We distinguish between Inbound Communication (an application/system/partner is calling SAP Cloud Integration) and Outbound Communication (SAP Cloud Integration is calling an application/system/partner). This article is looking at inbound only for PUSH-scenarios (where a communication component is actively sending data to the SAP Cloud Integration tenant).
Inbound Communication Authentication Options:
- Basic
- using the Identity Provider (IdP), which is SAP by default
- via Service Instances (see below)
- Please note: SAP does not recommend basic authentication (neither option) in productive scenarios.
- OAuth
- Client Credentials (via Service Instances)
- Certificate
- via Service Instances
- via Integration Flow*
*Certificates can also be used directly (not within a Service Instance Keys which are using roles). There are Pros and Cons of maintaining certificates in an iFlow (you have to change and redeploy each iFlow), but there might be a very specific case where you have to go this way (e.g. for some standard SAP scenarios like B2G Elster in Germany). You can use certificates issued by SAP or so-called External Certificates (however they must be signed by a Certificate Authority (CA) which is supported by SAP´s load balancer.
User Roles control the Authorization (access) to individual Integration Flows.
The standard role ESBMessaging.send is selected through Sender Communication Channels, but can be also changed to a different value. The authorization we look at here is only relevant for Systems and Applications. For User Authorizations (Access Policies) we will provide another Blog Post in the near future.
You can assign a user role to a user or to a Service Instance (see below).
Basic (IdP)
To assign a role to a user you go to the SAP BTP Cockpit (Subaccount – Section Security) and create a Role Collection.
In this Role Collection you select the role (created automatically from Cloud Integration) and assign it to (a) user(s):
Service Instances are created in the SAP BTP Cockpit.
- You can create multiple service instances, one for each use case, which is typically defined by different User Roles.
- For messaging runtime only the Plan “integration-flow” is relevant
- The Runtime Environment MUST BE Cloud Foundry (even though you might be able to select Kyma or Kubernetes)
- You have to select Grant Type “Client Credentials”, others are not relevant
The following scheme is showing the approach of using several Service Instances using individual roles in different Integration Flows:
This applies for all authentication types via Service Instances, even for Certificate-based authentication, where the certificate is also mapped to a user role.
Within each service instance, you create Service Keys for the individual access (one key for each application/partner). You will see that each the user name (clientid) remains static and only the password (clientsecret) is changing for each key. Please note that you can not assign a client certificate to multiple service instances. Of course you can maintain multiple client certificates in one service instance (via multiple service keys).
Does it make sense to create one service instance with one key for each B2B partner? We do not recommend so, as the overhead would be huge. Even if a partner knows the URL patterns (and naming conventions) for individual iFlows and technically they might be able to invoke another partners interface, we have additional security in place:
For AS2 connectivity you work with certificates and signatures. You decrypt and verify the signature of an individual connectivity:
For other SOAP/HTTP/OData connectivity you might want to position an API Management in between to better control incoming traffic towards APIs you provision in an API portal.
A comment on Outbound Communication: This is much easier to configure and clearly depends on the application/partner which is called, however we might have to consider the use of SAP Cloud Connector (to reach an On-Premise where we can not use certificates) and the fact how we are accessing our partners. From an On-Premise system we were using a (forward) internet proxy and its IP-address used to be quite static (or a list of maybe 5 IP-addresses). In the SAP BTP context you will have to communicate a larger list of IP Address Ranges to your partners…
