Ariba Security Protocols Upgrade in SAP-PI/PO
This blog is to provide an overview of Ariba Security Protocols Upgrade and the mandatory adoption of TLS 1.1/1.2
This blog is intended for the following audiences:
- Business users of SAP Ariba
- SAP PI Consultants
- SAP Ariba Consultants
- SAP BASIS Consultants
STRUCTURE AND USAGE
This blog is an overview of Ariba Security Protocols Upgrade and the mandatory adoption of TLS 1.1/1.2.
The blog provides the information to restrict TLS protocol version in server with TLS1.1 and TLS 1.
This blog doesn’t contain scheduling the ITK Jobs with the Advanced Front door URLs to connect to P2P/SAP MM
This blog doesn’t explain the SAP Ariba landscape for Legacy Front Door, Advanced Front Door and Integration Front Door which is required for the introduction of the dedicated integration URLs.
Why Ariba Security Protocols Upgrade?
To maintain the PCI [Payment Card Industry] compliance and continue securing our customer’s information at the highest industry standards, SAP Ariba is upgrading its security protocols and ciphers and removing the weak or insecure ones.
To implement this new security protocols we need to separate integration traffic from browser traffic. As a part of this we will be making a dedicated communication channel available for integration traffic which will allow SAP Ariba and customers to separate integration traffic from browser traffic.
Once it is achieved we can implement new security protocols as they become available, helping us to secure your data much more efficiently. The new integration-only URLs are TLS 1.1 / 1.2 compliant and are currently available.
P.S: SAP Ariba encourages all On Demand customers to upgrade to Java™ 8 to protect against any security vulnerabilities that are discovered.
What is the impact of not taking any action?
Browser based traffic (i.e. browser traffic using the UI) and Single Sign-On: If using a compatible browser, no action is needed.
Inbound and/or Outbound integration traffic: If no action is taken, as stated earlier you may no longer have access to SAP Ariba Applications or the Ariba Network once TLS 1.1/1.2 compliance is enforced.
What if I am on an unsupported version of Cloud Integration (CI)?
If you are using versions CI-1 through CI-4 will need to upgrade to CI 9 SP2 to maintain access to SAP Ariba Applications and the Ariba Network. This upgrade should start immediately. If you are on CI-5 through CI-8 you must implement the latest hot fix to become compliant.
If neither actions are taken you may no longer have access to SAP Ariba Applications or the Ariba Network once TLS 1.1/1.2 compliance is enforced.
How do I know which version of CI I am on?
Open ESR application and Sort/Filter by “Group Software Components”, CI versions can be identified as show in the below reference picture.
Outbound from Ariba Network: Enabling TLS 1.1/1.2
A white-list is used to enable the Ariba Network to initiate outbound communication using TLS 1.1/TLS 1.2 on a URL by URL basis.
What is TLS, SHA2, Diffie-Hellman, and RC4?
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).
Secure Hash Algorithm 2 (SHA-2, also called SHA-256) is a cryptographic hash function that is used to determine the integrity of data.
Diffie-Hellman Key Exchange is a method of securely exchanging cryptographic keys which does not require the two parties exchanging keys to have any prior knowledge of each other to jointly establish a shared secret key. This key can then be used to encrypt subsequent communications.
RC4 is a stream cipher used to encrypt communications of variable length. It is considered insecure due to multiple vulnerabilities that have been discovered recently.
Steps to enable the custom configuration of TSL Protocols or Outbound communication using IAIK library
To get this done PI and BASIS Teams have to work in Tandem.
Default configuration is stored in iaik_ssl.jar in folder /usr/sap/<SID>/J21/j2ee/cluster/bin/ext/mail-activation.
iaik_ssl.jar contains a SSLContext.properties in folder iaik\security\ssl, listing the default config parameters.
# SSLContext properties
# supported since ISASILK 4.4
# Location of configuration file is iaik/security/ssl/SSLContext.properties within CLASSPATH
# It can be redefined with system property iaik.security.ssl.configFile
# e.g.java -Diaik.security.ssl.configFile=file:c:/java/SSLContext.properties
# allowLegacyRenegotiation is set to true otherwise we cann’t communicate with unpatched peers
# unsecure renegotiation is disabled for SSL server but remains allowed for client SSL
#deactivated to avoid regressions after ISASIK5.102
#avoid issues with IIS server
PI Team or BASIS Team have to just add the custom parameters to restrict the TLS Protocol version without affecting the code in SSLContext.properties file.
Once parameters were added, file has to be saved with the name ssl.config.
Recommendation: Copy the values known from SSLContext.properties to avoid problems.
Important custom parameters are listed below:
To enable custom configuration, one has to set the property “iaik.security.ssl.configFile”. This is possible using the ConfigTool.
To set the property “iaik.security.ssl.configFile” in SAP NWA, follow the below steps:
SAP NWA–>Configurations–>Infrastructure–>Java System Properties–>System VM Parameters
Add the properties as below:
Once the properties were added, the changes will be activated only after restarting the instance which will be done by BASIS Team.
URLs in PI channels
(For Ariba Network Interfaces) to be modified to new integration URLs to make them TLS 1.1/1.2 compliant
For incoming integrations, customers will need to convert their -2 URLs to the delineated integration traffic URLs
For browser-based traffic:
- Customers will need to enter a service request to convert their realm back to the legacy front door (s1.ariba.com)
- For SSO, customers will need to perform a configuration on their end so that the
URL now points to legacy URLs (s1.ariba.com instead of s1-2.ariba.com)
All these steps should be performed Test Environment first and when ready, should complete the same changes in the Production Environment.