Configuring SAP Cloud Integration

The actual authentication of inbound connections is handled by the hosting environment. Within the integration flow, you only define which authorization an authenticated user must have to be allowed to call the respective integration flow. Authorizations are reflected by user roles that can be assigned to specific users or groups/role collections.

On the Sender tab of an integration flow's Configure dialog, you can define which User Role a caller must have. Make sure that the Authorization dropdown is set to User Role for that and the desired user role is selected as shown in the following screenshot.

The default user role is ESBMessaging.send. Additional roles can be defined, which will be discussed in the environment-specific sections, as well as the maintenance of users and their assignments.

In the Neo environment, roles and the assignments to users or groups are maintained in the BTP Cockpit. The relevant places are:

• Roles: To create new or maintain existing roles, navigate to Applications → Subscriptions → Subscribed Java Applications → choose the "*iflmap" application → Roles
• Role Assignment: To assign roles to users or groups, navigate to Security → Authorizations

You can find more details about Authorizing Users or User Groups on the SAP Help Portal.

After assigning the appropriate role to a particular user, this user can call integration flows that require the respective role after successful authentication. In test environments, this could be easily set up by using basic authentication with the user's user ID (usually S- or P-user) and the password.

In productive environments, client certificates are recommended. Instead of uploading client certificates to every integration flow, which could cause big maintenance efforts when the certificate needs to be renewed, this can be achieved with the Certificate-to-User Mapping.

The Certificate-to-User Mapping allows you to map a client certificate to a particular user ID with a particular role assigned. That enables clients to use client certificates for authentication while still getting the right authorization assigned. The Certificate-to-User Mapping can be maintained within Cloud Integration in the Monitoring/Operations area:

You can find more details on setting up inbound connections in the Neo environment in the SAP Help Portal.

In the Cloud Foundry environment, additional roles can be maintained in the Cloud Integration WebUI, in the Monitoring area, via the User Roles tile. The following screenshot shows the navigation path and the maintenance screen with the pre-defined role ESBMessaging.send and a custom role CustomMessagingSend:

The assignment of roles to users, role collections, or service keys is carried out in the BTP Cockpit from the respective subaccount.

You can assign this role to Identity Provider (IdP) users using the menu Security → Users, Roles, or Role Collections.

An alternative to IdP users are service keys. Service keys can be compared to technical users. You can create them under the process integration runtime instance and can use them for basic authentication as well as client certificates.

To create service keys, navigate to Services → Instances and Subscriptions and select your process integration runtime instance or create a new one. Make sure that the configuration parameters of the instance contain the grant type "Client_credentials" and the respective role that your integration flows require. This can be done via the From or the JSON input. A sample JSON containing the default role and the custom role could look as follows:

12345678910
{
  "grant-types": [
    "client_credentials"
  ],
  "redirect-uris": [],
  "roles": [
    "ESBMessaging.send", "CustomMessagingSend"
  ],
  "token-validity": 3600
}

You can create new Service Keys in the respective section, as the following screenshot shows. As Key Type, you can choose between the following three options:

• ClientId/Secret: Generates a clientid and a clientsecret that can be used as a username and password for basic authentication.
• Certificate: Generates a new client certificate including the certificates of the issuing certificate authorities, and the key pair in the Base64 format. Hence, this can be used as a client certificate in another system. (Converting the file format might be required, for instance to a p12-file that can store all these pieces of information in a single file.)
• External Certificate: Allows you to upload an existing certificate that must be trusted by the Load Balancer.

The following screenshot shows a brief summary of the most relevant options when using service keys, with the configuration parameters on instance level (A), a sample service key for basic authentication (B), and a service key for client certificate-based authentication (C):

You can find more details on setting up inbound connections in the Cloud Foundry environment on the SAP Help Portal.

Authentication credentials towards receiver systems are not maintained directly inside integration flows. Instead, the integration flow only references the credentials. The authentication method can be controlled with the Authentication parameter within the Configure dialog.

There are two options for the integration flows of this course:

• For Basic Authentication, a second field Credential Name is displayed. This field needs to be filled with the name of a previously created security artifact. This artifact contains the username and the password for authenticating against the respective receiver system. It can be created in the Operations/Monitoring view under Manage Security → Security Material.

• If Client Certificate is chosen, a second field Private Key Alias is displayed. This field needs to be filled with the name of a key pair from the keystore that can also be found in the Operations/Monitoring view under Keystore.

  Each Cloud Integration tenant is delivered with a default key pair provided by SAP with the name: sap_cloudintegrationcertificate. By selecting it in the keystore and choosing Download → Certificate Chain, you can download the certificate chain for maintaining the receiver system.

When selecting multiple integration flows by marking the checkbox at the beginning of each row, you can select the Actions button on top of the table to Mass Configure those integration flows. A dialog box opens listing the selected integration flows and the configuration screen next to it. Although you still have to work through the selected integration flows for maintaining the parameters, this feature helps to keep track when configuring multiple integration flows because they are displayed in a new window where you can quickly enter all relevant details without leaving the Configure dialog.

Configuration parameters of the integration flows used for the SAP Sales and Service Cloud integration with SAP S/4HANA are very similar.

The Sender tab contains parameters that are relevant for the sending system, such as the Address or path where the worker node listens for incoming messages and what Authorization is required to be allowed to send data to the integration flow.

The Receiver tab contains parameters of the target system, like the Host, Port and Authentication details. With the Proxy Type set to On-Premise, it's possible to specify that the target system is reachable via the Cloud Connector. For all other locations, Internet is used (even if the target system is located inside an on-premise network, but a reverse proxy is used).

The following screenshot shows the Configure dialog for the integration flow Replicate Business Partner from SAP Business Suite, where the sender is SAP S/4HANA and the receiver is an SAP Sales and Service Cloud tenant.

Although SAP Sales and Service Cloud offers the code list mapping, some codes can't be mapped due to technical limitations of the interface or data type. In such cases, the value mapping on SAP Cloud Integration can solve the problem.

The mapping of ABC/Customer Classification between SAP Sales and Service Cloud and SAP ERP that can be seen in the previous screenshot is a good example for that:

• The identifier in SAP ERP is called CustomerClassificationCode and can contain values with a length of 2 (for example, "07").
• The identifier in SAP Sales and Service Cloud is called CustomerABCClassification and is limited by the data type of the field to a maximum length of 1 (for example, the value "A").

As the data type of the field in SAP Sales and Service Cloud does not allow values longer than 1, the system throws an error if such a value is received. Independent of maintained code list mapping entries, as the code list mapping can only be applied after the message has been read. But the correctness of data types is verified during reading the message. Hence, a value mapping inside SAP Cloud Integration must be used in this case.