When we talk about outbound communication where Cloud Integration acts as client, we must mention that Cloud Integration doesn’t offer any choices about how the user associated with the outbound request should be authorized to execute certain actions in the receiver system.
Therefore, as integration developer, you can’t specify any authorization options. This situation is plausible for the following reason: How the permissions of a calling entity are checked can only be defined by the technical capabilities of the server (in the outbound communication case, the receiver system). Because Cloud Integration (as a client in this case) can’t decide which technical capabilities are offered by the receiver system, SAP Cloud Integration cannot allow you to specify any authorization options in a receiver adapter.
However, in a receiver adapter, you can specify the Authentication option supported by the client (Cloud Integration, in this case). You can easily verify this fact by creating a receiver channel that supports HTTP communication (e.g., a receiver HTTP adapter), as shown below.
Specifying an Authentication option makes sense because SAP Cloud Integration can provide the required artifacts for each authentication option.
The sections below summarize the different authentication options available and provides information on the related integration artifacts to considering when configuring each communication option.
Basic
Cloud Integration is authenticated against a receiver system based on user credentials (user name and password).
When you configure basic authentication for outbound communication, you need to complement the related receiver adapter setting by defining a security artifact that contains the credentials (a User Credentials artifact).
This option is supported by the following receiver adapter types: AS2, AS4, OData V2, OData V4, HTTP, IDoc, ODC, SOAP SAP RM, SOAP 1.X, SuccessFactors OData V2, XI.
Client Certificate
Cloud Integration is authenticated against a receiver system based on a client certificate.
A client certificate (including public and private key) and a receiver server root certificate, which is accepted by the receiver, need to be part of the Keystore deployed on the tenant. In the receiver adapter settings of the integration low, the private key alias of the certificate can be modified to indicate a specific key pair must be used for this step. If you don’t specify a private key alias, any appropriate key in the keystore is used.
This option is supported by the following receiver adapter types: Ariba, AS2, AS4, OData V2, HTTP, IDoc, SOAP SAP RM, SOAP 1x, XI.
Principal Propagation
Cloud Integration is authenticated against a receiver system by forwarding the identity (principal) of the user (associated with the inbound request) to the SAP Cloud Connectivity service and from there to the receiver system (which can be, e.g., an on-premise SAP system).
Consequently, this option can only be selected when you’ve chosen On-Premise for the Proxy Type option, meaning you’ve configured outbound connectivity to an on-premise system through the SAP Connectivity service.
Setting up a scenario with this authentication option requires comprehensive configuration steps at the inbound and outbound side of Cloud Integration, as well as in the SAP Connectivity service and the receiver back-end system.
This option is supported by the following receiver adapter types: OData V2, HTTP, IDoc, ODC, SOAP (1.x), XI.
OAuth (When Using Twitter or Facebook Adapter)
Cloud Integration calls Twitter or Facebook using OAuth authentication mechanisms.
A Secure Parameter artifact is required to store the OAuth credentials.
This authentication option is supported by the Twitter and Facebook receiver adapter types. This option isn’t offered for the other HTTP-based adapters.
OAuth2 SAML Bearer Assertion (OAuth2 Client Credentials)
Cloud Integration is authenticated against a receiver system based on an access token received through an OAuth workflow.
Certain receiver adapters also offer the following OAuth variants: OAuth2 SAML Bearer Assertion and OAuth2 Client Credentials. To set up a scenario with such an authentication option, you also need to deploy an OAuth2 Credentials artifact to further specify the details for the OAuth outbound authentication (e.g., the address of the authentication server) in the Monitor section of the Web UI under Manage Security (Security Material tile).
The following receiver adaptor types support the option OAuth2 Client Credentials: AMQP/WebSocket, OData V2, OData V4, HTTP.
The following receiver adapter types support the option OAuth2 SAML Bearer Assertion: OData V2, HTTP, SAP SuccessFactors OData V2.
None
If this option is selected, no authentication is required for the tenant when calling a receiver system.
Note that, to have the permission to deploy security-related artifacts, your user must have been assigned the required roles, for example, the authorization group Auth-Group.Administrator.
Proxy Type: The following adapter settings are relevant in the context of configuring the Authentication setting Principal Propagation.
In most HTTP-based adapters (e.g., the SOAP and IDoc adapters), you’ll find the attribute Proxy Type. In the scenarios we cover in this book, we always kept the default setting of this attribute (Internet), which ensures that the tenant can connect to another system through the internet (e.g., over HTTP).
The other option for the Proxy Type attribute is On-Premise. Using this option, the tenant can connect to an on-premise system through SAP Connectivity services.
When setting up such a scenario, you’ll also need to install an additional component, The SAP Connectivity services, referred to as the cloud connector, in your on-premise landscape, that acts as proxy for requests that try to access your on-premise system coming from the internet.
If you use multiple cloud connector instances in your system landscape, you’ll also need to specify a Location ID. With this attribute, you can identify the cloud connector instance you want to use for your connection.
Learn more about SAP and the cloud here.
11
Editor’s note: This post has been adapted from a section of the book Cloud Integration with SAP Integration Suite The Comprehensive Guide by John Mutumba Bilay, Shashank Singh, Swati Singh, Peter Gutsche, and Mandy Krimmel.
Comments