In this Lesson, the Following Topics are Discussed:
- Inbound Security for Adapters.
- Inbound Security for an HTTP based Adapter.
Inbound Security for Adapters
Two cases need to be distinguished: establishing a secure connection to the load balancer and authenticating at the Cloud Integration tenant where the integration flow is implemented. To establish a secure connection, a Transport Layer Security (TLS) procedure is used over TCP (Transport Control Protocol)-based connections, and certificates are employed. This procedure is used in HTTPS, IMAPS, POP3S, SMTPS, FTPS, and other protocols. In the exercises of this training, we will use the SOAP adapter.
We want to explore the available options for ensuring that only authorized senders can send messages to our integration flow. This topic is referred to as Inbound Security.
The certificates required to establish an HTTPS connection between the sender and the load balancer are necessary.
The sender's authorization is validated against the integration flow endpoint.
Establishment of the HTTPS Connection
Recall the technical overview discussed in a previous lesson, which shows a Load Balancer between the sender and the endpoint URL of our deployed integration flow. As a result, it is necessary to establish the SSL connection between the sender and the Load Balancer.
The responsibility of importing all the required certificates lies with SAP, as we do not have access to the load balancer in cloud integration.
Authorization of the Sender Against the Endpoint of the Integration Flow
There are also two options available here:
- Authentication can be performed directly against the remote tenant where the integration flows are deployed.
- Usage of an authentication client (OAuth) on your own tenant.
Authentication can be performed directly against the remote tenant where the Integration Flows are deployed
This is the most common scenario during development, however, it is not recommended for production use. This option is marked in red as No. 1 in the picture above.
- Create your integration flow sender adapter and choose User Role as Authorization.
- At User Role, choose the available user roles.
- The default user role is ESBMessaging.send.
- Assign the user role ESBMessaging.sendto a Role Collection.
- Assign your Role Collection to a user at your subaccount.
- Call the endpoint with a user who is assigned to your Role Collection with the ESBMessaging.send role included.
It is not recommended to use client certificates for authorization. This approach requires importing a client certificate directly into the configuration.
A_sendMessagesToCI with the role MessagingSend assigned to two users.
The role MessagingSend in the context of this situation is equivalent to the role ESBMessaging.send in the Cloud Integration.
You will get a successful call to the endpoint using one of the assigned users.
Set your own User Role at Cloud Integration
You may want to use your own user roles. To set your own user role, navigate to Monitor Artifacts → Integrations → Mange Security → User Roles, and set your own role.
Set your own user role, for example, Peter1:
Then, as previously described, you can configure your own user role:
- Create a Role Collection.
- Assign your own user role to your own Role Collection.
- Assign the Role Collection to a user.
Usage of an Authentication (OAuth) Client on your own Tenant
The method of directly calling an integration flow via the role-based approach shown uses personalized users and basic authentication, which are not suitable for productive purposes. For better authentication methods, we need to use a self-configured OAuth2.0 client that can be created on our own subaccount.
To accomplish this, we need to set up a Process Integration Runtime instance on our subaccount, and associate it with the integration flow plan. This instance can then be customized with various client credentials. These correspond to No. 1 and No. 2, marked in blue in the picture above.
You can choose the following grand-types:
- Authorization Code
- Client Credentials
- Refresh Token
- SAML2 Bearer
- JWT Bearer
Selection of grand types when configuring the local Process integration Runtime instance.
- Create a local Process integration Runtime instance.
- Configure the appropriate grand-type.
- Create a key.
- Use the key parameters for authorization.
The new Process Integration Runtime instance of plan integration-flow.
Sample - Log on with ClientID and ClientSecret
Use the clientID as user and the clientsecret as password.
Sample - Log in with Bearer Token
Use the tokenURL with clientIS as user, and the clientsecret as password to generate a Bearer token.
Use the Bearer token for authentication.
Sample - Log in with OAuth 2.0 Authentication
You can use OAuth 2.0 for authentication, which involves two steps: first, generating a token, and second, using that token for authorization.
Read more here:
Secure communication involves two steps: establishing a secure connection to the load balancer and authenticating at the Cloud Integration tenant where the integration flow is implemented. This is achieved by using certificates in TCP (Transport Control Protocol) based connections via TSL (Transport Layer Security) procedure. These protocols include HTTPS, IMAPS, POP3S, SMTPS, FTPS, and others. Many protocols such as SOAP, OData, HTTP, also use these secure communication protocols.
Authentication at the endpoint of the integration flow can be accomplished in two ways: direct assignment of a user role to a user or the use of a local OAuth 2.0 client that offers additional authentication options, such as ClientId/Clientsecret, Bearer Token, or OAuth 2.0. These methods are not personalized and are more secure than the first option.