Using Adapter Inbound Security

Objective

After completing this lesson, you will be able to use and set up an inbound security adapter

Inbound Security Adapter

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 must 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 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.

Screenshot of 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.
The diagram shows the sender authorization process. Information about authentication is provided in the following text.

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 preceding picture.

Procedure

  • 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.send to 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.

Note

It is not recommended to use client certificates for authorization. This approach requires importing a client certificate directly into the configuration.

Screenshot of the connection details. Information is provided in the following text.

Role Collection, A_sendMessagesToCI with the role MessagingSend assigned to two users.

Screenshot of the configuration of A_sendMessagesToCI.

Note

The role MessagingSend in the context of this situation is equivalent to the role ESBMessaging.send in the Cloud Integration.

You get a successful call to the endpoint using one of the assigned users.

Screenshot of the successful call of the endpoint.

Set your own User Role at Cloud Integration

You can 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.

Choose Monitor Artifacts → Integrations → Mange Security → User Roles.

Set your own user role, for example, Peter1:

Set your own user role.

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.
Screenshot of user roles.

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 must use a self-configured OAuth2.0 client that can be created on our own subaccount.

To accomplish this, we must 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 preceding picture.

You can choose the following grand-types:

  • Authorization Code
  • Client Credentials
  • Password
  • Refresh Token
  • SAML2 Bearer
  • JWT Bearer

Selection of grand types when configuring the local Process integration Runtime instance.

Screenshot of setting parameters. Information on the procedure is provided in the following paragraph.

Procedure

  • 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.

Screenshot of the new process integration runtime.
Screenshot of selection of grand types. In this case, we use Client Credentials.
Screenshot of the created key with key type: ClientID/Secret.
Screenshot of the key parameter.

Sample - Log on with ClientID and ClientSecret

Use the clientID as the user and the clientsecret as the password.

Screenshot of the set up of a sample ClientID and ClientSecret.

Sample - Log in with Bearer Token

Use the tokenURL with clientIS as user, and the clientsecret as password to generate a Bearer token.

Screenshot of the setup of a sample with Bearer token.

Use the Bearer token for authentication.

Screenshot of using 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.

Screenshot of OAuth 2.0 for authentication, which involves two steps: generating a token and using that token for authorization.

Resources

Read more here:

Summary

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 the 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 extra 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.

Create an Inbound SOAP Adapter

Business Scenario

To initiate the process by receiving a SOAP message containing the list of ProductIDs, it's necessary to set up a SOAP-type inbound adapter.

Task Flow

In this exercise, you will perform the following tasks:

  1. Log on to the integration flow DelayedDelivery_Process.
  2. Create an Inbound SOAP Adapter.
  3. Save as version and deploy your integration process.

Prerequisites

The task of substituting the timer event with a message start event has been completed.

Outcome After This Exercise

You will get familiar with how to use and configure an inbound SOAP adapter in the integration flow.

What do you Learn Within This Exercise?

You will gain familiarity with configuring and using an inbound SOAP adapter in the integration flow.

Outcome.

Steps

  1. Log on to the integration flow DelayedDelivery_Process via SAP Integration Suite.

    1. Navigate within the SAP Integration Suite Welcome page to Design → Integrations → DelayedDelivery_Package_CLD900_Date_Number → DelayedDelivery_Process_Number.

    2. Following the status after the last exercise step.

      Starting.

    3. Imagine that the integration flow has been further edited.

  2. Rename the Sender.

    1. Choose the Sender component and change the name to Sender_startSOAPMessage.

      Renaming.

  3. Create an Inbound SOAP Adapter.

    1. Create and configure an Inbound SOAP Adapter.

    2. Drag the arrow from the context menu of the Sender_startSOAPMessage to Event_Start_Message.

      Create the soap adapter.

    3. Choose SOAP → SOAP 1.x.

      Message protocol.

    4. Switch to the Connection tab of the configuration bar. Enter the following data.

      Field NameInput Data
      Address/receive/message/DelayedDelivery_ProductIDs_Date_Number (must be unique)
      Service DefinitionManual
      Use WS-Addressingunflagged
      Message Exchange PatternOne-Way (starting asynchronous)
      Processing SettingsWS standard
      AuthorizationUser Role
      User RoleESBMessaging.send
      Soap config.

  4. Save as version, deploy, and debug your integration process.

    1. Perform the following steps.

      1. Save as version.
      2. Deploy.
      3. Jump to Overview → Manage Integration Content.
      4. Set the log level to trace.

    2. The process is initiated and waits for an incoming SOAP message. The endpoint to start the process looks like this:

      Code Snippet
      1
      https://int-cust-demo-store-xxxxxxxxxxxxxxxxxxxt.cfapps.eu10-003.hana.ondemand.com/cxf/send/<your_defined_address_in_the_soap_adapter>
      Monitoring.

    3. Currently, we do not have the option to send a message to the endpoint.

Allow the Sender to Send Messages to the Endpoint of the iFlow

Business Scenario

We want to enable a channel to send messages to the endpoint, and to do this we must assign a user the role of ESBMessaging.send, which is part of a Role Collection. Another way to define a role is by using a local process integration runtime, which can be assigned to a user.

Task Flow

In this exercise, you will perform the following tasks:

  1. Check the role ESBMessaging.send at Cloud Integration.
  2. Create a Role Collection at your SAP BTP subaccount.

Prerequisites

You have completed the final step of creating an Inbound SOAP Adapter.

Outcome After This Exercise

You will have configured security for your endpoint, which allows your integration flow to receive messages.

What do you Learn Within This Exercise?

You will learn how to implement role-based inbound security for an integration flow.

Task 1: Check the Role of ESBMessaging.send at Cloud Integration

Steps

  1. Find the configured role ESBMessaging.send at Cloud Integration.

    1. Choose Monitor → Integrations and APIs.

      Choose Monitor → Integrations and APIs.

    2. Find Manage Security → User Roles .

      Choose Manage Security > User Roles.

    3. The role is defined but not yet assigned to a user.

Task 2: Create a Role Collection in the SAP BTP Subaccount

Steps

  1. Create a Role Collection in your SAP BTP subaccount.

    1. Navigate to the overview side of your SAP BTP subaccount.

      Choose Manage Security > Role Collections.

    2. Choose the Role Collections menu entry.

    3. Choose the Create button for a new Role Collection. Set the name SendMessagesToCI.

      Choose Create.

    4. Use the search bar to navigate to your new Role Collection with the name SendMessagesToCI.

      Set up a role collection.

    5. Choose the Edit button and choose the Role Name search.

      Select the role.

    6. To take over the entry for MessagingSend, search for it and select the checkbox in the corresponding role. Only then will the role be applied.

    7. Choose the Add button at the bottom right.

    Note

    The role MessagingSend corresponds to the Cloud Integration role ESBMessaging.send.

  2. Assign the Role Collection to a user.

    1. Assign in the ID area, a user to this Role Collection by typing the ID into the ID field. To add the ID, press Enter.

      Screenshot of the ID mapping.

    2. Choose the Save button.

    3. Now, we have a defined MessagingSend role that corresponds to the ESBMessaging.send role at No. 1, and an assigned user to this role via a Role Collection at No. 2.

Create an HTTP Client to Send SOAP Messages to an iFlow

Business Scenario

We will now explore one method to send messages to an integration flow - using Postman. It is important to be cautious while entering user and password details. Entering an incorrect password three times results in the user being blocked for an hour.

Task Flow

In this exercise, you will perform the following optional tasks:

  1. Use the Postman HTTP Client to send a message to the integration flow.
  2. Use curl to send a message to the integration flow.
  3. Create an HTTP Client with Business Application Studio.

Prerequisites

The last step has been completed, which involved creating an Inbound SOAP Adapter. As a result, your integration flow has been deployed and now has an endpoint.

Outcome After This Exercise

You now have the capability to send messages to the DelayedDelivery_Process using various HTTP clients.

What do you Learn Within This Exercise?

You will learn how to configure and use the Postman HTTP client for sending a SOAP message to the DelayedDelivery_Process.

Task 1: Use Postman HTTP Client to Send a Message to the Integration Flow

Steps

  1. Get the Postman app or use it via the web.

    1. You can download the Postman API platform from: https://www.postman.com/downloads/ for free.

    2. Choose Workspaces.

    3. Choose the Create Workspace button.

      In the Postman app, choose Workspaces and then choose Create Workspace.

  2. Configure a workspace.

    1. Enter a name and a description.

    2. Choose the Create Workspace button.

      In the Postman app, setup a name and choose Create Workspace.

    3. To create a collection in your new workspace DelayedDelivery_Process, choose the New button .

      To create a collection, choose New.

  3. Configure a collection within the workspace.

    1. Choose the Collection button.

      Choose Collection.

    2. Rename the collection to DelayedDelivery_Process_Collection. You now have a Workspace at No. 1 and a collection at No. 2.

      Screenshot of the new workspace.

  4. Configure an HTTP request.

    1. Choose the New button and choose HTTP Request.

      Choose HTTP Request.

    2. Enter your Endpoint URL of your DelayedDelivery_Process.

      Screenshot of the Endpoint URL at monitoring.

    3. First, change the method to POST.

      Change the method to Post.

    4. Choose Authorization → Inherit auth fr.. → Basic Auth and enter your user and password of this user, which has assigned the Role Collection SendMessagesToCI.

      Screenshot of the authorization screen.

    5. Choose the Body tab.

    6. Choose raw → XML.

      Choose Body, and then XML to set the Payload.

    7. Enter the following SOAP message.

      Note

      It is possible to verify that the Product IDs exist in the database.

      Code Snippet
      1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Header/>
 <soapenv:Body>
 <List>
 <Product>
 <ProductID>HT-2001</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1020</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1035</ProductID>
 </Product>
  <Product>
 <ProductID>HT-6101</ProductID>
 </Product>
  <Product>
 <ProductID>HT-7000</ProductID>
 </Product>
   <Product>
 <ProductID>HT-2026</ProductID>
 </Product>
  <Product>
 <ProductID>HT-6100</ProductID>
 </Product>
  <Product>
 <ProductID>HT-9994</ProductID>
 </Product> 
 <Product>
 <ProductID>HT-1254</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1031</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1035</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1601</ProductID>
 </Product>
 <Product>
 <ProductID>HT-2025</ProductID>
 </Product>
 <Product>
 <ProductID>HT-1067</ProductID>
 </Product>
 </List>
 </soapenv:Body>
</soapenv:Envelope>

    8. Choose the Save  button and rename your HTTP request while saving. 

  5. Send a Message.

    1. Choose the Send button.

      Screenshot of the accepted Status. Then, choose Send.

  6. Navigate to Integration Suite → Monitor → Overview → Manage Integration Content.

    1. Choose Monitor Message Processing.

      Screenshot of the Artifact Details and the Log Configuration.

    2. Choose Completed → Trace.

      Choose Completed > Trace.

    3. The process runs smoothly without any errors.

      Screenshot of the whole integration process flow.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn