Update from SAP DITA CMS (squashed):

commit 62e37e0913331a6191c37cc56b8627c236df46bd
Author: REDACTED
Date:   Wed Jul 17 09:46:11 2024 +0000

    Update from SAP DITA CMS 2024-07-17 09:46:11
    Project: dita-all/slu1713332208086
    Project map: 6d6c94be23b547a19d534f13dd6d51a7.ditamap
    Output: loiocc0ab4c7365e43bbbee9eae27deb32da
    Language: en-US
    Builddable map: 446771d4951c4a6988252269c21d94ba.ditamap

commit 77c486f9bf8d9078c1447f2ceb650d0bd4c217f9
Author: REDACTED
Date:   Wed Jul 17 01:14:08 2024 +0000

    Update from SAP DITA CMS 2024-07-17 01:14:08
    Project: dita-all/slu1713332208086
    Project map: 6d6c94be23b547a19d534f13dd6d51a7.ditamap
    Output: loiocc0ab4c7365e43bbbee9eae27deb32da
    Language: en-US
    Builddable map: 446771d4951c4a6988252269c21d94ba.ditamap

commit 650f7c82883279b615358fe536cd321dd8f72843
Author: REDACTED
Date:   Tue Jul 16 23:12:50 2024 +0000

    Update from SAP DITA CMS 2024-07-16 23:12:50
    Project: dita-all/slu1713332208086
    Project map: 6d6c94be23b547a19d534f13dd6d51a7.ditamap
    Output: loiocc0ab4c7365e43bbbee9eae27deb32da
    Language: en-US
    Builddable map: 446771d4951c4a6988252269c21d94ba.ditamap

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

docs/ISuite/40-RemoteSystems/creating-service-instance-and-service-key-for-inbound-authentication-19af5e2.md

@@ -167,7 +167,12 @@ Create a service instance to implement inbound communication. A service instance
 
     The selection of roles depend on the chosen option for *Plan*.
 
-    -   When as *Plan* you've chosen *integration-flow*, you can either keep the standard role `ESBMessaging.send` or enter a custom role \(see [Managing User Roles](../50-Development/managing-user-roles-4e86f0d.md)\).
+    -   When as *Plan* you've chosen *integration-flow*, you can either keep the standard role `ESBMessaging.send` or enter a custom role.
+
+        The default role `ESBMessaging.send` is already predefined. To define a custom role, go to the *Monitor* view of SAP Integration Suite, and select the *User Roles* tile in the *Manage Security* section \(for more information, see [Managing User Roles](../50-Development/managing-user-roles-4e86f0d.md)\).
+
+        > ### Note:  
+        > Custom roles for this use case are **not** defined using the SAP BTP cockpit.
 
         You're able to add multiple roles by selecting enter after each role. The default is set to the standard role \(`ESBMessaging.send`\).
 
@@ -389,6 +394,11 @@ With this step, you create a service key for the instance.
     > 
     > -   or one certificate with pinning enabled and another certificate with the same subjectDN and issuerDN where pinning is disabled.
 
+    > ### Note:  
+    > Starting from version 8.18.x, Edge Integration Cell runtimes use a local component to perform inbound certificate authentication. This component categorizes all service keys of type *External Certificate* as pinned, regardless of whether the *Pin Certificate* setting is enabled or disabled.
+    > 
+    > As such, even if you've renewed a client certificate and *Pin Certificate* is disabled, you're still required to create a new service key that includes your updated certificate. For more information, see [Edge Local Authentication and Authorization](../edge-local-authentication-and-authorization-510d447.md).
+
 
     
     </td>

docs/ISuite/40-RemoteSystems/inbound-message-level-security-with-openpgp-d2acb9f.md

@@ -72,10 +72,37 @@ To implement message-level security for OpenPGP, you use PGP keys.
 
 ![](images/Keys_for_Message_Level_Security_PGP_Inbound_0c58adc.png)
 
+
+
+## Configuring the Sender
+
+1.  Generate and configure the PGP keys and the storage locations \(PGP secret and public keyrings\) for the sender system.
+
+2.  Import the related public keys from the tenant into the public PGP keyring of the sender and finish the configuration of the sender system.
+
+
+
+
+Provide the tenant administrator with the public key \(is used to verify messages sent to the tenant\).
+
+
+
+## Configuring the Integration Flow Steps for Message-Level Security
+
+Configure the security-related integration flow steps.
+
+Configure the **Decryptor** \(PGP\) and **Verifyer** \(PGP\) step.
+
+When signatures are expected, make sure that you specify the *Signer User ID of Key\(s\) from Public Keyring* for all expected senders.
+
+Based on the signer user ID of key\(s\) parts, the public key \(for message verification\) is looked up in the PGP public keyring. The signer user ID of key\(s\) key parts specified in this step restrict the list of expected senders and, in this way, act as an authorization check.
+
 **Related Information**  
 
 
 [How OpenPGP Works](how-openpgp-works-29bc188.md "You can use Open Pretty Good Privacy (Open PGP) to digitally sign and encrypt messages.")
 
 [Creating OpenPGP Keys](creating-openpgp-keys-6c5846b.md "You use the tool gpg4win to create the required keys for the usage of OpenPGP.")
 
+[Define PGP Decryptor](../50-Development/define-pgp-decryptor-d0dc511.md "")
+

docs/ISuite/40-RemoteSystems/inbound-message-level-security-with-pkcs-7-xml-digitalsignature-9d6bd42.md

@@ -72,6 +72,40 @@ To implement message-level security for the standards PKCS\#7, WS-Security, and
 
 ![](images/Certificates_for_Message_Level_Security_Inbound_dbc7998.png)
 
+
+
+## Configuring the Sender
+
+Configure the sender keystore in the following way:
+
+-   Generate a key pair \(and get it signed by a CA\).
+
+-   Import the tenant public key into the sender keystore.
+
+
+
+
+Provide the tenant administrator with the public key \(is used to verify messages sent to the tenant\).
+
+
+
+## Configuring the Integration Flow Steps for Message-Level Security
+
+Depending on the desired option, configure the security-related integration flow steps.
+
+-   Configure the **Verifyer** \(PKCS7 or XML Signature Verifyer\) step.
+
+    Specify the *Public Key Aliases* in order to select the relevant keys from the tenant keystore.
+
+-   Configure the **Decryptor** \(PKCS7\) step.
+
+    Make sure that you specify the *Public Key Aliases* for all expected senders \(only if you have specified *Enveloped or Signed and Enveloped Data* or *Signed and Enveloped Data* for *Signatures in PKCS7 Message*\).
+
+    These are the public key aliases corresponding to the private keys \(of the expected senders\) that are used to sign the payload. The public key aliases specified in this step restrict the list of expected senders and, in this way, act as an authorization check.
+
+
+In general, an alias is a reference to an entry in a keystore. A keystore can contain multiple public keys. You can use a public key alias to refer to and select a specific public key from a keystore.
+
 **Related Information**  
 
 
@@ -83,3 +117,5 @@ To implement message-level security for the standards PKCS\#7, WS-Security, and
 
 [Creating Keys for the Usage of PKCS\#7, XML Digital Signature and WS-Security](creating-keys-for-the-usage-of-pkcs-7-xml-digital-signature-and-ws-security-6f43916.md "To set up message level security scenarios based on PKCS#7, XML Digital Signature or WS-Security, the required keys are created in the same way as for transport level security HTTPS.")
 
+[Define PKCS\#7/CMS Decryptor](../50-Development/define-pkcs-7-cms-decryptor-51d903b.md "")
+

docs/ISuite/40-RemoteSystems/introduction-10dc4a3.md

@@ -217,7 +217,7 @@ Sender adapter
 </td>
 <td valign="top">
 
-Allows SAP Integration Suite to consume messages from queues or subscriptions in SAP Integration Suite, advanced event mesh.
+Allows SAP Integration Suite
 
 See: [Configure the Advanced Event Mesh Sender Adapter](../50-Development/configure-the-advanced-event-mesh-sender-adapter-abd2efc.md)
 
@@ -764,6 +764,22 @@ See: [Configure the AzureStorage Receiver Adapter](../50-Development/configure-t
 <tr>
 <td valign="top">
 
+*Coupa*
+
+Receiver adapter
+
+</td>
+<td valign="top">
+
+Enables SAP Integration Suite to exchange data with Coupa. Coupa is a business spending management software.
+
+See: [Coupa Receiver Adapter](../50-Development/coupa-receiver-adapter-648ac01.md)
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
 *Data Store*
 
 Sender adapter
@@ -1314,6 +1330,22 @@ See: [Configure the Microsoft SharePoint Receiver Adapter](../50-Development/con
 <tr>
 <td valign="top">
 
+*NetSuite* 
+
+Receiver adapter
+
+</td>
+<td valign="top">
+
+Connects SAP Integration Suite to NetSuite. NetSuite is an integrated cloud business software suite, including business accounting, ERP, CRM, and e-commerce software.
+
+See: [NetSuite Receiver Adapter](../50-Development/netsuite-receiver-adapter-618127a.md)
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
 *OData* 
 
 Sender adapter

docs/ISuite/40-RemoteSystems/involved-roles-3968091.md

@@ -4,3 +4,69 @@
 
 The security artifact renewal process requires that different persons perform a sequence of steps in a coordinated way on each side of the communication. The exact sequence depends on the kind of security material which is renewed and on the use case.
 
+**Roles in the Security Artifact Renewal Process**
+
+
+<table>
+<tr>
+<th valign="top">
+
+Role
+
+</th>
+<th valign="top">
+
+Tasks
+
+</th>
+</tr>
+<tr>
+<td valign="top">
+
+Sender/receiver administrator \(at customer side\)
+
+</td>
+<td valign="top">
+
+Updates the security artifacts owned by the sender/receiver back-end system \(for example, the keystore\).
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+Integration developer
+
+</td>
+<td valign="top">
+
+Updates the integration flow in certain use cases.
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+Tenant administrator
+
+</td>
+<td valign="top">
+
+Updates the security artifacts of the tenant \(relevant for outbound communication\).
+
+</td>
+</tr>
+<tr>
+<td valign="top">
+
+Load balancer administrator
+
+</td>
+<td valign="top">
+
+Updates the security artifacts of the load balancer \(relevant for inbound communication\).
+
+</td>
+</tr>
+</table>
+

docs/ISuite/40-RemoteSystems/message-level-security-463a908.md

@@ -79,9 +79,7 @@ Encryption/decryption and signing/verification of payload
 </td>
 <td valign="top">
 
-Supported algorithms \(by the symmetric key\) for content encryption \(format Cipher/Operation Mode/Padding Scheme\): AES/CBC/PKCS5Padding, ARCFOUR/ECB/NoPadding, Camellia/CBC/PKCS5Padding, CAST5/CBC/PKCS5Padding, DES/CBC/PKCS5Padding, DESede/CBC/PKCS5Padding, RC2/CBC/PKCS5Padding.
-
-Signature algorithms: MD5/RSA, RIPEMD128/RSA, RIPEMD160/RSA, RIPEMD256/RSA, SHA/RSA, SHA224/RSA, SHA256/RSA, SHA384/RSA, SHA512/RSA.
+Signature algorithms: AES/GCM/NoPadding, AES/CCM/NoPadding, MD5/RSA, RIPEMD128/RSA, RIPEMD160/RSA, RIPEMD256/RSA, SHA/RSA, SHA224/RSA, SHA256/RSA, SHA384/RSA, SHA512/RSA.
 
 This is a subset of the algorithms that are supported for PKCS\#7/CMS Enveloped Data and Signed Data.
 
@@ -131,7 +129,7 @@ Encryption/decryption and signing/verification of the message
 </td>
 <td valign="top">
 
-Supported signature algorithms for PGP signing: MD5, RIPE-MD/160, SHA-1, SHA224, SHA256, SHA384, SHA512.
+Supported signature algorithms for PGP signing: MD5, RIPE-MD/160, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512.
 
 </td>
 </tr>

docs/ISuite/40-RemoteSystems/outbound-message-level-security-with-openpgp-8641a15.md

@@ -72,10 +72,38 @@ To implement message-level security for OpenPGP, you use PGP keys.
 
 ![](images/Keys_for_Message_Level_Security_PGP_Outbound_8e6a163.png)
 
+
+
+## Configuring the Receiver
+
+1.  Generate the PGP keys and the storage locations \(PGP secret and public keyrings\) for the receiver system.
+
+2.  Import the related public keys from the tenant into the public PGP keyring of the receiver and finish the configuration of the receiver system.
+
+
+
+
+Provide tenant administrator with the public key \( used to encrypt messages sent to the receiver\).
+
+
+
+## Configuring the Integration Flow Steps for Message-Level Security
+
+Depending on the desired option, configure the security-related integration flow steps.
+
+Configure the **Encryptor** \(PGP\) step.
+
+-   Specify the *User ID of Key\(s\) from Public Keyring* in order to select the relevant public receiver keys from the PGP public keyring.
+
+-   If you want to sign the payload, specify the *Signer User ID of Key\(s\) from Secret Keyring* in order to select the relevant private key from the PGP secret keyring. The private key is used to sign the message.
+
+
 **Related Information**  
 
 
 [How OpenPGP Works](how-openpgp-works-29bc188.md "You can use Open Pretty Good Privacy (Open PGP) to digitally sign and encrypt messages.")
 
 [Creating OpenPGP Keys](creating-openpgp-keys-6c5846b.md "You use the tool gpg4win to create the required keys for the usage of OpenPGP.")
 
+[Define PGP Encryptor](../50-Development/define-pgp-encryptor-7a07766.md "")
+

docs/ISuite/40-RemoteSystems/outbound-message-level-security-with-pkcs-7-xml-digitalsignature-57b2b19.md

@@ -74,6 +74,21 @@ To implement message-level security for standards PKCS\#7, WS-Security, and XML
 
 
 
+## Configuring the Receiver
+
+Configure the receiver keystore in the following way:
+
+-   Generate a key pair \(and get it signed by a CA\).
+
+-   Import the tenant public key into the receiver keystore.
+
+
+
+
+Provide the tenant administrator with the public key \(is used to encrypt messages sent to the receiver\).
+
+
+
 <a name="loio57b2b199a17a49f1844bba06076f4be1__section_sqk_d2t_5bb"/>
 
 ## Configuring the Integration Flow Steps for Message-Level Security
@@ -104,3 +119,7 @@ In general, an alias is a reference to an entry in a keystore. A keystore can co
 
 [Creating Keys for the Usage of PKCS\#7, XML Digital Signature and WS-Security](creating-keys-for-the-usage-of-pkcs-7-xml-digital-signature-and-ws-security-6f43916.md "To set up message level security scenarios based on PKCS#7, XML Digital Signature or WS-Security, the required keys are created in the same way as for transport level security HTTPS.")
 
+[Sign the Message Content with PKCS\#7/CMS Signer](../50-Development/sign-the-message-content-with-pkcs-7-cms-signer-cc09e03.md "")
+
+[Encrypt and Sign the Message Content with PKCS\#7/CMS Encryptor](../50-Development/encrypt-and-sign-the-message-content-with-pkcs-7-cms-encryptor-21fd211.md "")
+

docs/ISuite/40-RemoteSystems/renewal-of-password-only-84dabed.md

@@ -8,3 +8,10 @@ To exchange the password of a user without any downtime, the cloud infrastructur
 
 Security artifact renewal has to be performed in the following sequence:
 
+1.  Cloud infrastructure provider: Informs the sender administrator that he wants to change the password of a certain user used for HTTPS communication with the tenant and that he has created an **intermediate user** \(`user1`\) and password.
+2.  Sender administrator: Exchanges the old user/password \(`user0`\) with the intermediate user/password \(`user1`\) in the HTTPS sender client \(back-end system\).
+3.  Sender administrator: Informs the cloud infrastructure provider that the sender client now uses the intermediate user \(`user1`\).
+4.  Cloud infrastructure provider: Informs the sender administrator that the password of the original user \(`user0`\) has been changed.
+5.  Sender administrator: Exchanges the user/password of the intermediate user \(`user1`\) with the original user \(`user0`\) \(and with the new password\).
+6.  Sender administrator: Informs the cloud infrastructure provider that user and password has been changed.
+

docs/ISuite/40-RemoteSystems/renewal-of-tenant-client-root-certificate-ca-8dc5877.md

@@ -35,6 +35,17 @@ Certificate renewal has to be performed in the following sequence:
 8.  Tenant administrator: Informs the receiver administrator that a new client certificate \(signed by another CA than the old one\) is now used.
 9.  Receiver administrator: Removes the old client certificate and also the old root certificate \(assumed that it is not longer used in any other communication\).
 
+Let us assume, the customer landscape is composed as described under *Connecting a Customer System to Cloud Integration*, section *Technical Landscape for On Premise-On Demand Integration*. In that case, SAP Web Dispatcher is used to receive incoming calls from the cloud. SAP Web Dispatcher \(as reverse proxy\) is the entry point for HTTPS requests into the customer system landscape. The configuration of the receiver \(server\) as indicated in step 2 in the list above comprises the following tasks for that example case:
+
+-   Make sure that the reverse proxy trusts the new CA. A restart is required to finalize the related configuration steps.
+-   Map the new certificate in AS ABAP back-end for authentication purpose
+-   Edit the new CA in Web Dispatcher farm.
+
+    This step is performed by SAP IT.
+
+-   Upload the new CA in workcenter under *Edit Certificate Trust List*.
+-   Update the communication arrangements credentials such way that the new certificate is mapped to the inbound technical user.
+
 
 
 ## Receiver does not Accept Different Certificates at the same Time

docs/ISuite/40-RemoteSystems/renewal-of-user-and-password-da1eeb1.md

@@ -6,3 +6,6 @@ In this use case, the user \(through which a sender calls the tenant\) is replac
 
 Security artifact renewal has to be performed in the following sequence:
 
+1.  Sender administrator: Changes the user and password in the HTTPS sender client \(sender back-end\).
+2.  Sender administrator: Informs SAP that user has been changed in the sender client.
+