New Features and Enhancements

This topic summarizes the new features and enhancements for the current release of the
Layer7 API Gateway
. Also included is an Addendum section that describes some of these items in greater detail.
CGW10-0
2

What's New in Gateway Version 10.0 CR4

Description
Notes
Support for New JSON Web Signatures
For organizations interested in RFC7518 compliance, the Gateway now supports the following JWS algorithms:
  • PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256)
  • PS384 (RSASSA-PSS using SHA-384 and MGF1 with SHA-384)
  • PS512 (RSASSA-PSS using SHA-512 and MGF1 with SHA-512)
More Luna Partition Policy Changes for Luna HSM Users
Additional Luna partition policy changes have been introduced for this release. You may now turn the following policies OFF:
  • Policy 2: Enable Private Key Unwrapping
  • Policy 5: Allow Secret Key Wrapping
  • Policy 6: Allow Secret Key Unwrapping
  • Policy 17: Allow Signing with Non-Local Keys
  • Policy 33: Allow RSA PKCS Mechanism
The ability to turn these policies off gives users additional flexibility in tailoring their HSM to security requirements while maintaining native Gateway functionality; however, users must be aware of some caveats resulting from turning these policies off, as described here

What's New in Gateway Version 10.0 CR3

Description
Notes
Support for TLS v1.3
For improved security, TLS 1.3 is now supported for HTTP, HTTP2, and WebSocket connections. New listen ports and WebSocket connections are now set to TLS 1.2 and TLS 1.3 by default upon creation. For new HTTP routing assertions, you can see
TLS 1.3
option in the TLS drop-down lists.
TLS 1.3 option is not selected by default for existing listen ports. For existing routing assertions, if you have used
<Any>
as the TLS version in the configuration properties and if backend supports TLS 1.3, the route call goes via TLS 1.3 after you upgrade to API Gateway 10 CR3.
Ensure that the following cipher suites are enabled when
TLS 1.3
option is selected:
  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
Note:
TLS 1.3 is available on AdoptOpenJDK 8u275.
Support for AdoptOpenJDK
Beginning with version 10.0 CR3, the API Gateway now supports AdoptOpenJDK 8u275.
The JDK-8253368 issue leads to more frequent full TLS handshakes while routing to the backend. Layer7 introduced a new cluster-wide property to manage this JDK issue.
For more information, see the known issue here: JDK Regression Issue with AdoptOpenJDK 8u275 for TLS 1.2.
Support for CryptoComply for Java (CCJ) v3.0.1
Applies to FIPS users of the Gateway. The SafeLogic CryptoComply for Java (CCJ) library, a FIPS-compliant cryptographic engine providing FIPS functionality for the Gateway, has been upgraded to version 3.0.1.
Version 3.0.1 is a major release and enforces stricter security guidelines per FIPS 140-2. It now restricts a private key to one set of functions either to decrypt/encrypt OR sign SSL certificates but not both. To maintain backwards compatibility, this new system property has been set to 'true'. However it is recommended that this property is set to 'false' for increased security:
com.safelogic.cryptocomply.rsa.allow_multi_use=false
Importing a keystore in JKS format into the Gateway using Policy Manager is not permitted by the CCJ v3.0.1 library but has been enabled by the Gateway to preserve backwards compatibility. Going forward, if you typically import JKS formatted keystores, it is recommended that you convert them to PKCS #12 format prior to importing.
Please be aware that SafeLogic's refreshed architecture and design behind CCJ v3.0.1 may pose some performance tradeoffs on cryptographic operations to accommodate improved security features as required by FIPS.
Support for Kerberos Authentication when Token Compression is Enabled
Kerberos authentication in API Gateway is now supported when Kerberos Token compression is enabled. In Microsoft Active Directory 2012 and later versions, the resource SID compression is enabled by default, which enables Kerberos Token compression during Kerberos authentication.
Support for nShield Client version 12.60.11
The Gateway now supports nShield Client version 12.60.11. nShield HSM users planning upgrade to Gateway version 10.0 CR 3 are REQUIRED to upgrade their nShield Client to version 12.60.11. To Learn more about the nShield client upgrade process:
  • For users of the appliance Gateway form factor, see here.
  • For users of the software Gateway form factor (requires an additional nShield hotfix), see here.
Support for Luna HSM Client version 10.2
The Gateway now supports Luna HSM Client version 10.2 (i.e., the Luna Universal Client). Luna HSM users planning to upgrade to Gateway version 10.0 CR 3 are REQUIRED to upgrade their Luna HSM Client to version 10.2 along with a Thales patch file. Learn more about the client upgrade process here.
More Luna Partition Policy Changes for Luna SA HSM Users (Applies to Client versions 7.2 and 10.2)
Additional Luna partition policy changes have been introduced for this release. You may now turn the following policies OFF:
  • 'Allow Secret Key Wrapping' (Policy #5)
  • 'Allow Signing with Non-Local Key' (Policy #17)
The ability to turn these policies off gives users additional flexibility in tailoring their HSM to security requirements while maintaining native Gateway functionality; however, users must be aware of some caveats resulting from turning these policies off, as described here.
Changes in Cipher Suite
The default recommended cipher suite list for Gateway has been modified. The list is reordered and it includes the following new cipher suites:
  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
Policy Manager Support for MacOS X
Mac users can now install the Policy Manager on their MacOS X operating system as described here.

What's New in Gateway Version 10.0 CR2

Description
Notes
Enhancements for the
serviceUsage.updateInterval
cluster property
The
serviceUsage.updateInterval
was first introduced for CR1, giving users the option to disable/enable the Gateway's ability to collect service metrics data and write them to the internal MySQL database, giving enterprises more flexibility in their solution architecture. For CR2, this property has been further enhanced to allow users to tune the frequency of service metrics by way of time units. See Service Cluster Properties to learn more.
Telemetry data now sent to Broadcom
PLA customers will now send telemetry data from their Gateways to Broadcom directly at
https://telemetry.broadcom.com
instead of Segment. See Telemetry Data  to learn how to activate and learn more about the telemetry requirement as part of the Broadcom PLA agreement.
Support for AdoptOpenJDK
For version 10.0 CR2, API Gateway supports AdoptOpenJDK 8u265.
Support for Oracle X8-2 Appliance
CA API Gateway v10.0 CR2 now supports the Oracle X8-2 hardware appliance.
Luna Partition Policy Changes for Luna SA HSM v7.2 Users
The 'Enable Private Key Unwrapping' Luna partition policy (also known as Policy ID #2) has a factory default of 'ON'. If your enterprise requires to have this policy turned off to ensure that public/private key pairs are created and stored within the Luna HSM, you may now do so without impacting the general operation of the Gateway. If you run your Luna SA HSM in FIPs mode, you'll need to make additional configuration changes as described here.
Note that this is the first phase of Layer7's goal to make the Gateway amenable to changes for a select number of Luna partition policies.

What's New in Gateway Version 10.0 CR1

Description
Notes
AdoptOpenJDK Support
For version 10 CR1, API Gateway supports AdoptOpenJDK 8u252.
nShield Hardware Security Module Support for Software Gateways
Previously, only the appliance form factor of the API Gateway supported integration with the nShield Connect XC HSM. With the release of version 10 CR1, Gateway support for this device has been extended to the software form factor. See here for installation and configuration information.
The scripts and files required for nShield HSM configuration on the software Gateway are packaged in a 'ssg-nshield-10.0.00.10675-CR01.tar.gz' tarball file within the '10-CR01.zip' file.  See here for its contents and additional configuration instructions.
'Select Solution Kits by Name' Enhancement for Headless Management of Gateway Solution Development Kits
The API Gateway now enables users to conveniently select Solution Kits by a text-based name when installing, upgrading or uninstalling them headlessly via the Gateway Migration Utility (GMU) or RESTMAN tools. Previously, when installing, upgrading, or uninstalling Solution Kits such as OTK from the Gateway, users were restricted to selecting Solution Kits by their Globally Unique Identifier), which made the identity of the Solution Kit less obvious to the user.
To learn more about the new
solutionKitSelectByName
property for the GMU tool, see the manageSolutionKits command page. For RESTMAN API, refer to RESTMAN documentation.
New
serviceUsage.updateInterval
Cluster Property
The new cluster-wide property,
service.Usage.updateInterval
, lets you opt out of the data collection of service usage statistics to free up system resources for the Gateway database where this statistical data is written to. Learn more about this property in the Service Cluster Properties page.
The
service.Usage.updateInterval
property, as described for Gateway Version 10 CR1, reflects the first phase of its rollout. For the second phase (official release to be announced) this property will also allow you to tune the frequency or intervals (in Time Units) of service usage data collection.
New WebSocket assertion
The Connect to Outbound WebSocket assertion allows you to establish an outbound WebSocket connection using a specified WebSocket connection entity that is selected implicitly from the policy context.
CA SSO SDK Upgrade
CA Single Sign-On SDK is upgraded to version
12.8.03
. For more information, see List of Update Files, Requirements and Compatibility, and Install the CA Single Sign-On SDK for Software Gateways.
New
maxEventsPerSecond
Advanced Listen Port Property
By default, HTTP/2 listen port allows each host to send 20 events per second. You can now configure an advanced property, maxEventsPerSecond=<value>, to allow more events per second. This property overrides the cluster property value, http2.transport.maxEventsPerSecondDefault.
New 'Use This Order' Option in SSL/TLS Settings (Policy Manager)
Implemented a new 'Use this Order' option in the Policy Manager > Manage Listen Ports > Listen Port Properties > SSL/TLS Settings tab  for the Gateway to enforce the use of a server-side cipher suite to bypass the potential problem of a client's preference to use a client-side cipher suite for a secure connection handshake.
Will This New Option Be Automatically Selected When I Upgrade to Gateway Version 10 CR1?
The option will be selected by default if you are performing a
  • Brand-new or from-scratch install of Gateway version 10 CR1
  • Gateway migration to version 10 CR1 via a bundle using an existing Gateway running version 10 (base) or version 9.4 (any CR).
If you are performing a standard upgrade from a Gateway running version 10 (base) or version 9.4 (any CR), this option will NOT be selected by default.

What's New in Gateway Version 10.0

Description
Notes
CentOS 7 Support
At General Availability, all Gateway 10 OVA images except for Software Gateway will come shipped with CentOS 7.7.1908.
See the What's New in CentOS 7 section of the Addendum to this page for more information on the applicability of CentOS 7 across the different Gateway form factors.
Expedited Appliance Upgrades
Gateway version 10.0 currently is not offered as an in-place upgrade. If you are upgrading from any previous 9.x versions of the Gateway, back up and migrate all of your policies and policy artifacts to Gateway 10.0 via the Manual Expedited Appliance Upgrade process.
If you are migrating multiple appliance Gateways from Gateway 9.4 to Gateway 10.0, you may also consider using the Automated Expedited Upgrade procedure.
Software Gateway customers may upgrade to version 10.0 via the standard patching process.
MySQL 8 Support
To prepare for the End-of-Service-Life timeline of MySQL 5.7, Gateway version 10.0 will come shipped with MySQL 8.0 as the primary store for Gateway configurations, metrics and logs.
If you are planning to perform the MySQL upgrade as part of the Gateway version 10.0 upgrade, your experience may vary depending on the versions of your current production Gateway and MySQL server. For a summary of the upgrade paths, including known limitations, please see Using MySQL 8.0 with Gateway 10.
HTTP(S) Listen Port Server Engine Upgrade
The API Gateway has upgraded its Listen Port server engine for handling HTTP(S) requests. You can learn how to optimally configure select input/output cluster wide properties for Gateway version 10.0+ as a result of this upgrade by referring to the Performance Tuning for HTTP(S) Listen Port Server Engine section of the Addendum to this page.
SafeNet Luna SA HSM Client v7.2 Support
Layer7 API Gateway now supports the Luna SA Network HSM v7.2 client. To learn how to perform a clean installation of the client, see  Configure the SafeNet Luna SA HSM v7.2. If you're looking to upgrade from v5.4.1 of the client, see Upgrade the SafeNet Luna SA HSM Client.
Note
: Although Gemalto has announced that it will be ending its sale of v5.4.1 in early 2020, CA-Broadcom will continue to provide best-of-ability support for customers who plan to continue with v5.4.1 of the client. At the same time, however, Luna customers should be prepared for v7.2 becoming the standardized Luna HSM version moving forward.
Syslog Integration Improvements
Syslog properties are now configurable to allow improved management of message queues and connections for Syslog server implementations.
To configure Syslog properties
For a quick comparison of what the Syslog system default settings were versus the new configurable default settings, see the Syslog section in the Addendum to this page.
Support for HTTP/2 Protocol
Layer7 API Gateway now supports HTTP/2 protocol for inbound and outbound data transfers. The new Route via HTTP/2 assertion supports the HTTP 2.0 standards.
Support for OpenAPI 3.0 Specification
The new Validate Against OpenAPI Document assertion validates a request against the API from an OpenAPI document. You can use the new Publish OpenAPI Service wizard to publish a service based on an OpenAPI document.
Kafka Support
Layer7 API Gateway acts as a Kafka client (Producer) that publishes records to the Kafka cluster. The new Route via Kafka assertion enables the policy to route gateway messages to known Kafka clusters topic.
DFDL Support
Layer7 API Gateway now supports DFDL (Data Format Description Language) and provides the capability to manage precompiled  DFDL processors and drive data transformation using the Apply DFDL Transformation assertion.
ICAP Enhancements
The Scan Using ICAP-Enabled Antivirus assertion now supports REQMOD (Request Modification Mode) as well. Gateway can also now include preview data in the ICAP request that it sends to the ICAP server.
SSH2 Enhancements
You can now add a list of fingerprints and validate the SSH public key of the server against multiple fingerprints in the Route via SSH2 assertion.
Introduced a cluster property, ssh.routingEnabledKexAlgs, that specifies the ordered CSV list of all the enabled KEX algorithms that are used in SSH routing. You can select and order the KEX algorithms in the Route via SSH2 assertion.
Oracle 19c Support
Oracle 19c is supported.
MS Active Directory 2016 Certification
For the release of version 10.0, the
Layer7 API Gateway
is now certified against MS Active Directory 2016. Customers who no longer wish to use Active Directory 2008 (Microsoft plans to end product support in 2020) and require to use the more up-to-date Active Directory 2016 as the LDAP identity provider for their Gateways can now do so by upgrading to version 10.0 of the Gateway.
Extract Attributes from Certificate Assertion Enhancement
The Extract Attributes from Certificate assertion is now enhanced so you can choose to publish the Extension Values in the form of context variables by providing the Extension Object Identifiers in the assertion properties.

Addendum

What's New in CentOS7
RHEL/CentOS 6.x is scheduled to come to its end-of-life at the end of 2020, giving version 10.0 of the Layer7 API Gateway a prime opportunity to embrace CentOS 7.x, the next iteration of the popular Linux-based platform. Version 10.0, is available for the appliance (both hardware and virtual), software, and AMI/Azure form factors of the Gateway. The following is a summary of the technical changes introduced by CentOS 7.
CentOS 7 Introduces systemd
The switchover from sysvinit to systemd as the system and service manager: this means that certain configuration or installation commands for the Gateway must now use systemctl command conventions in the command line. For example, the systemctl command to reboot the appliance is now
systemctl reboot
instead of the older
reboot
command. Most of these commands will be executed as background processes - the majority of your Gateway configuration tasks should be completed in the SSG Configuration menu and/or restricted shell.
CentOS 7 Introduces Persistent Network Interface Naming
Network interfaces are no longer identified by the kernel-based "eth#" naming convention. To learn how the Gateway handles the new persistent network interface naming convention and how it may impact your configuration, see the Network Deployment Guide.
CentOS 7 Introduces New Services
CentOS 7 has introduced new system services and/or enabled or disabled existing ones as the system default. Off the shelf, version 10.0 of the Gateway has either enabled or disabled those services to ensure that your Gateway(s) run optimally and securely.

Syslog Improvements at a Glance

The following table compares the previous and new default values for each configurable syslog property.  Syslog properties were not configurable prior to version 10.0 of the API Gateway.
Property
Description
Old Default Value
New Configurable Default Value
Queue Size
The size of the log data length which will be stored in queue when the syslog is busy or not reachable.
For example: If set to 10, then the Gateway stores 10 log items in the queue per log sink.
200
10000
Connection Timeout
The connection timeout for each time when gateway trying to connect to a syslog server
30000ms
500ms
Max reconnect attempts
When any message is pending, gateway will start the reconnect process.  The number of reconnect attempts performed to a target syslog server. If there is only one syslog server configured, then this property doesn't apply - Gateway will try to reconnect indefinite number of times to that one syslog server.
6
1
Reconnect Interval
When any message is pending, gateway starts the reconnect process. The reconnect interval is the pause between each reconnect attempt.
N/A
1000ms
Drop Rate Percent
When syslog message queue is full, gateway will start to drop the old log message in at a percentage of queue size in order to make room for new messages. The number of oldest message is equal to (Drop Rate Percent) x (Queue size).
For example, When queue size is set to 10,000 and drop rate percent to 1, the number of message will be drop is 10,000 x 1% = 100
20%
1%

Performance Tuning for HTTP(S) Listen Port Server Engine

The following describes the optimal input/output configurations for Gateway version 10.0 running the latest HTTP(S) listen port server engine. For comparison purposes, the default settings are also shown.
You can learn more about the various input/output cluster wide properties in more detail by going here.
Property
Description
Default Settings
GW Version 10.0 Recommended Settings
Worker Thread Pool Core
io.httpCoreConcurrency
Sets the number (pool size) of concurrent active HTTP connections per Gateway node.
500
1800
Worker Thread Pool Maximum
io.httpMaxConcurrency
Sets the maximum number of concurrent HTTP and HTTPS connections (per Gateway node) that can be active simultaneously.
750
2000
Thread Count for Tomcat Acceptor (New for Gateway Version 10.0)
tomcat.acceptor.threadCount
Sets the number of threads to be used to accept connections.
2
2
Maximum Connections to Tomcat Acceptor (New for Gateway Version 10.0)
tomcat.acceptor.maxConnections
Sets the maximum number of connections that the Gateway will accept and process at any given time. When this maximum has been reached, the Gateway will accept, but not process, one further connection. This additional connection is blocked until the number of connections being processed falls below the given value at which point the Gateway will start accepting and processing new connections again.
If this setting is not configured, the system will automatically adjust the maximum number of connections to six times the value of
io.httpMaxConcurrency
. For example, if
io.httpMaxConcurrency
has a given value of 1500, then the maximum connections shall be 9000 (6x1500).
4500
12000