Update from SAP DITA CMS (squashed):

commit 70db00bbe8644d89c7e3460c5c0ec0ec3cb3d2e6
Author: REDACTED
Date:   Thu Sep 14 11:31:59 2023 +0200

    Update from SAP DITA CMS ( 2023-09-14_11:31:58 )

    Project: loio4e3938135e8b4504abd2de738751b03a (cdo1688560638547.project)

    * Project map: loio4e3938135e8b4504abd2de738751b03a (pjm1688552106128.ditamap)

    * Output: loio3268cb35959d4b368fb49de861bfe8a1

    * Buildable map: loio5069d95611d7478eaf67350d394e1ce8 ()

    * Language: en-US

commit 0ef80865340b6545410e7b63d01aa9af365daba2
Author: REDACTED
Date:   Thu Sep 14 10:40:43 2023 +0200

    Update from SAP DITA CMS ( 2023-09-14_10:40:43 )

    Project: loio6d6c94be23b547a19d534f13dd6d51a7 (sot1688618446815.project)

    * Project map: loio6d6c94be23b547a19d534f13dd6d51a7 (lnv1688552106211.ditamap)

    * Output: loiocc0ab4c7365e43bbbee9eae27deb32da

    * Buildable map: loio446771d4951c4a6988252269c21d94ba ()

    * Language: en-US

##################################################
[Remaining squash message was removed before commit...]

docs/ISuite/50-Development/http-receiver-adapter-2da452e.md

@@ -562,7 +562,7 @@ Description
 </td>
 <td valign="top">
 
-Enter a list of custom headers, separated by a pipe \(|\), that you want to send to the target system. By default, no custom headers are sent. Alternatively, use an `*` to send all custom headers to the target system.
+Enter a list of custom headers, separated by a pipe \(|\), that you want to send to the target system. By default, no custom headers are sent. Alternatively, use an `*` to send all custom headers to the target system. Alternatively, you can dynamically pass on the values by defining a property that includes a list of headers.
 
 > ### Remember:  
 > Use an `*` separately. If you use an `*` and custom header together that are separated by a pipe \(|\), only the custom header is considered.

docs/apim/API-Management/api-services-007d50f.md

@@ -84,7 +84,7 @@ A client software development kit \(SDK\) is available for developers through a
 
 In the API Portal, at the top-right corner, choose *Navigation Links* \(![](images/Finalgrid_1a621ca.png)\) and select *Client SDK* \(![](images/clientsdk_f85baa6.png)\). On selecting the client SDK, you are navigated to the maven repository, where you can download this package.
 
-For more information, see [SAP API Management, 1.4.0 Client SDK](https://help.sap.com/doc/3cf9060925e241e5968d54202f5e7365/CLOUD/en-US/SAP%20API%20Management%20Cloud%20SDK_1.4.0.pdf).
+For more information, see [SAP API Management, 1.5.0 Client SDK](https://help.sap.com/doc/sap-api-management-client-sdk/Cloud/en-US/SAP%20API%20Management%20Cloud%20SDK_1.5.0%20.pdf).
 
 You can also download the package from [https://mvnrepository.com/artifact/com.sap.apimgmt.client.sdk/apim-client-sdk](https://mvnrepository.com/artifact/com.sap.apimgmt.client.sdk/apim-client-sdk). On navigating to this link, select the latest version and choose *View All*.
 

docs/apim/API-Management/what-s-new-for-sap-api-management-d9d60be.md

@@ -110,6 +110,92 @@ API Management
 
 
 
+</td>
+<td valign="top">
+
+Client SDK
+
+
+
+</td>
+<td valign="top">
+
+In Cloud Foundry, Authentication using the X509 certificate and key is now supported. Instead of clientid, clientsecret and tokenurl, use certificate, privateKey, certUrl and clientid. For more information, refer to the Client SDK version 1.5.0 in [API Services](api-services-007d50f.md).
+
+
+
+</td>
+<td valign="top">
+
+Info only
+
+
+
+</td>
+<td valign="top">
+
+General Availability
+
+
+
+</td>
+<td valign="top">
+
+New
+
+
+
+</td>
+<td valign="top">
+
+Technology
+
+
+
+</td>
+<td valign="top">
+
+Not applicable
+
+
+
+</td>
+<td valign="top">
+
+
+
+
+
+</td>
+<td valign="top">
+
+2023-09-13
+
+
+
+</td>
+<td valign="top">
+
+2023-09-13
+
+
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+API Management
+
+
+
+</td>
+<td valign="top">
+
+-   Cloud Foundry
+
+
+
 </td>
 <td valign="top">
 

docs/ci/ConnectionSetup/authentication-and-authorization-options-inbound-983f2a5.md

@@ -0,0 +1,165 @@
+<!-- loio983f2a5f994146ab8daff1f97d6db3dd -->
+
+# Authentication and Authorization Options \(Inbound\)
+
+When a client calls a server using a secure communication channel, two different kinds of checks are performed subsequently.
+
+-   Authentication
+
+    Verifies the identity of the calling entity.
+
+-   Authorization
+
+    Checks what a user or other entity is authorized to do \(for example, as defined by roles assigned to it\). In other words, the authorization check evaluates the access rights of a user or other entity.
+
+
+When a client calls a server, it is first authenticated and, in a subsequent step, the authorization check is performed.
+
+We use **inbound** to refer to the communication direction when a sender system sends a message to the integration platform.
+
+
+
+## Combinations of Authentication and Authorization \(Inbound\)
+
+For inbound communication based on HTTPS, the authentication and authorization options can be combined in a specific way.
+
+**Combination of Authentication/Authorization Options**
+
+
+<table>
+<tr>
+<th valign="top">
+
+Authentication Option ...
+
+
+
+</th>
+<th valign="top">
+
+Can Be Used with the Following Authorization Option ...
+
+
+
+</th>
+</tr>
+<tr>
+<td valign="top">
+
+Basic authentication
+
+The sender \(client\) authenticates itself against the server based on user credentials \(user name and password\). The HTTP header of the inbound message \(from the sender\) contains the user name and password.
+
+
+
+</td>
+<td valign="top">
+
+Role-based authorization
+
+For this user, the authorizations are checked based on user-to-role assignments defined on the tenant.
+
+> ### Note:  
+> When you use Cloud Integration in the Cloud Foundry environment, as user credentials you can also use clientid and clientsecret from a Process Integration service instance with plan *integration-flow* and *client\_credentials* grant type.
+
+
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+Client-certificate authentication and certificate-to-user mapping \(only in the Neo environment\)
+
+The sender \(client\) authenticates itself against the server based on a digital client certificate. Furthermore, this certificate is mapped to a user \(based on the information contained in a *Certificate-to-User Mapping* artifact deployed on the tenant\).
+
+> ### Note:  
+> You can map multiple certificates to the same user \(n:1 certificate-to-user mappings possible\).
+
+
+
+</td>
+<td valign="top">
+
+Role-based authorization
+
+For the user derived from the certificate-to-user mapping, the authorizations are checked based on user-to-role assignments defined on the tenant.
+
+
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+Client-certificate authentication
+
+\(without certificate-to-user mapping\)
+
+The sender \(client\) authenticates itself against the server based on a digital client certificate.
+
+
+
+</td>
+<td valign="top">
+
+Subject/Issuer DN authorization check of a certificate
+
+In a subsequent authorization check, the permissions of the sender are checked on the tenant by evaluating the distinguished name \(DN\) of the client certificate of the sender.
+
+
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+OAuth
+
+Grants access to resources of SAP Cloud Integration without the need to share passwords with the client.
+
+> ### Note:  
+> This option is supported for the following sender adapter types: SOAP \(SOAP 1.x\), SOAP \(SAP RM\), HTTPS, and OData.
+
+
+
+</td>
+<td valign="top">
+
+Role-based authorization
+
+
+
+</td>
+</tr>
+</table>
+
+
+
+> ### Note:  
+> It is not recommended to use client certificate authentication \(without certificate-to-user mapping\). Instead of this, it is recommended to use client certificate authentication with certificate-to-user mapping \(which is a more secure way of authentication\).
+
+
+
+More information: [OAuth 2.0 Specification](https://oauth.net/2/)
+
+
+
+Note that there are major differences for the setup of inbound connections depending on whether you use Cloud Integration in the Cloud Foundry or Neo environment, see: .
+
+For detailed instructions on how to set up the different authentication options, see: [Environment-Specific Aspects Integration Developers Should Know](../InitialSetup/environment-specific-aspects-integration-developers-should-know-639a061.md).
+
+-   [Configuring Inbound HTTP Connections, Cloud Foundry Environment](configuring-inbound-http-connections-cloud-foundry-environment-f568400.md)
+
+-   [Configuring Inbound HTTP Connections, Neo Environment](configuring-inbound-http-connections-neo-environment-bd1dbc4.md)
+
+
+**Related Information**  
+
+
+[Protecting Applications with OAuth 2.0](https://help.hana.ondemand.com/help/frameset.htm?b7b589334d444293a2a91e0ef4234136.html)
+
+[Authentication Options \(Inbound\)](authentication-options-inbound-5495ee0.md "For inbound communication, different ways are supported how the sender can authenticate itself against Cloud Integration.")
+
+[Authorization Options \(Inbound\)](authorization-options-inbound-c98c87e.md "For inbound HTTPS requests, two different ways to check the authorization of the caller can be configured.")
+

docs/ci/ConnectionSetup/authentication-options-inbound-5495ee0.md

@@ -0,0 +1,40 @@
+<!-- loio5495ee0775004999a73ce72a074d6fc7 -->
+
+# Authentication Options \(Inbound\)
+
+For inbound communication, different ways are supported how the sender can authenticate itself against Cloud Integration.
+
+We use **inbound** to refer to the communication direction when a sender system sends a message to the integration platform.
+
+-   **Basic authentication**
+
+    The calling entity is authenticated based on credentials \(user name and password\)
+
+-   **Client-certificate authentication and certificate-to-user mapping**
+
+    The calling entity is authenticated based on a certificate, and the certificate is mapped to a user \(for which the authorization check is executed in a subsequent step\).
+
+-   **Client-certificate authentication** 
+
+-   OAuth 2.0
+
+    OAuth allows you to set up authentication scenarios without the need to share credentials.
+
+    See:
+
+    [Protecting Applications with OAuth 2.0](https://help.hana.ondemand.com/help/frameset.htm?b7b589334d444293a2a91e0ef4234136.html)
+
+    [OAuth 2.0 Specification](https://oauth.net/2/) 
+
+
+**Related Information**  
+
+
+[Basic Authentication](basic-authentication-2c4c2d9.md "Basic authentication allows a client to authenticate itself against the server based on user credentials.")
+
+[Client Certificate Authentication and Certificate-to-User Mapping \(Inbound\), Neo Environment](client-certificate-authentication-and-certificate-to-user-mapping-inbound-neo-environment-4b5afdd.md "This option includes an authentication step based on a digital client certificate and the mapping of the certificate to a user.")
+
+[Client Certificate Authentication \(Inbound\), Neo Environment](client-certificate-authentication-inbound-neo-environment-c1eeeab.md "This option includes an authentication step based on a digital client certificate.")
+
+[Setting Up Inbound HTTP Connections \(with OAuth\), Neo Environment](setting-up-inbound-http-connections-with-oauth-neo-environment-e5cb7ea.md "")
+

docs/ci/ConnectionSetup/authentication-options-outbound-58a7537.md

@@ -0,0 +1,26 @@
+<!-- loio58a75377cc154f44bb81c0376d330901 -->
+
+# Authentication Options \(Outbound\)
+
+For outbound communication through HTTPS \(when the tenant sends a message to a receiver\), the following authentication options are supported.
+
+-   **Basic authentication**
+
+    The calling entity \(tenant\) is authenticated based on credentials \(user name and password\)
+
+-   **Client-certificate authentication**
+
+    The calling entity \(tenant\) is authenticated based on a certificate.
+
+-   OAuth
+
+
+**Related Information**  
+
+
+[Basic Authentication](basic-authentication-a5d77b1.md "Basic authentication allows a the tenant to authenticate itself against the receiver through credentials (user name and password).")
+
+[Client Certificate Authentication \(Outbound\)](client-certificate-authentication-outbound-c4e4a15.md "")
+
+[OAuth 2.0](oauth-2-0-3823134.md#loio382313443b8d4453b0fd536b82b9e15d "OAuth 2.0 allows a user to grant a client access to a protected resource (hosted by a resource server). The user typically restricts the access of the client and doesn't allow full access.")
+

docs/ci/ConnectionSetup/authorization-options-inbound-c98c87e.md

@@ -0,0 +1,28 @@
+<!-- loioc98c87e2882c43d49cc70abfd943a90d -->
+
+# Authorization Options \(Inbound\)
+
+For inbound HTTPS requests, two different ways to check the authorization of the caller can be configured.
+
+We use **inbound** to refer to the communication direction when a sender system sends a message to the integration platform.
+
+-   **Role-based authorization**
+
+    The permissions of the calling entity \(user\) are checked based on a user-to-role assignments configured in the associated identity provider.
+
+    In the related sender adapter, you can assign the role based on which the inbound authorization is to be checked for the integration flow.
+
+-   **Subject/Issuer DN authorization check**
+
+    The distinguished name \(DN\) of a certificate \(associated with the calling entity\) is checked.
+
+    Subject/Issuer DN authorization check can be defined for individual integration flows.
+
+
+**Related Information**  
+
+
+[Role-Based Authorization](role-based-authorization-62a0336.md "This option allows you to define permissions for users in the connected identity provider (by default, SAP Identity Service) and to perform an authorization check based on these settings.")
+
+[Subject/Issuer DN authorization check](subject-issuer-dn-authorization-check-3c0fdde.md "It is checked (for a specific integration flow) if the subject/issuer distinguished name (DN) of the assigned certificate matches the incoming certificate.")
+