Document version: 29 April 2016
This Readme applies to Axway API Gateway 7.4.0 SP 4 on all platforms. The information in this Readme supersedes any corresponding information in the documentation (online or printed) previously supplied for the product. This service pack is cumulative and includes all updates from previous API Gateway 7.4.0 service packs.
The main aim of this service pack is to provide fixes for a number of reported defects. This service pack contains updates for:
The service pack contains new binaries only and does not overwrite the existing configuration.
File packages: An installation archive is provided for all platforms (for example,
APIGateway_7.4.0_SP4_Core_win-x86-32_BNYYYYMMDDn.zip
for Windows).
Size: The file size differs for each platform. The MD5 checksum is provided for each file.
This service pack provides the following corrections and enhancements:
Case ID | Internal ID | Description |
---|---|---|
808644 | RDAPI-1066 |
Issue: Cassandra-backed client application registry is not correctly migrated. Note: You must configure an authentication policy for login to the client application registry. To enable the authentication policy in Policy Studio, select Server Settings > Security > Client Application Registry, and set Circuit for authentication to point to the policy. For an example authentication policy, see |
810590 | RDAPI-1165 | Issue: Extract MTOM filter returns incorrect Content-Type for SOAP 1.2. Resolution: Previously, when a SOAP 1.2 request was sent to the Extract MTOM filter, the startinfo parameter of the content-type header in the outer package was text/xml , and the type parameter of the content-type header in the root part was text/xml.
Now, when a SOAP 1.2 request is sent to the Extract MTOM filter, the startinfo parameter of the content-type header in the outer package is application/soap+xml , and the type parameter of the content-type header in the root part is application/soap+xml , as required by the specification: https://www.w3.org/TR/soap12-mtom/#mime-serialization. |
800386 | RDAPI-1869 |
Issue: OAuth authorization code flow in v7.4 prompts to authorize for scopes. |
818782 | RDAPI-2124 | Issue: Proxy authentication fails for HTTPS requests. Resolution: Previously, the Connect To URL filter was not sending the Proxy-Authorization header to proxy for HTTPS requests (tunneling) when required.
Now, the Connect To URL filter sends the Proxy-Authorization header to proxy for HTTPS requests (tunneling) as required. |
818438 | RDAPI-2133 | Issue: Cache attribute filter does not fail when cannot set key in cache. Resolution: Previously, the Cache attribute filter did not return false if the object failed to be added to the cache. Now, the Cache attribute filter returns false if the object fails to be added to the cache. |
813470 | RDAPI-2143 | Issue: Memory Leak in CRL (Dynamic) filter. Resolution: Previously, I/O streams were not closed in case of errors during CRL processing. Now, I/O streams are closed when they are no longer needed. |
820016 | RDAPI-2147 | Issue: API Gateway waits indefinitely after sending 100-continue response.Resolution: Previously, the API Gateway would wait, in all cases, for a 100-continue response from the server on a HTTP 1.1 connection before sending a message body. If the server did not send a 100-continue response (or it was lost in the network path), the API Gateway would wait until the connection timeout value was reached, and then close the connection.
Now, when you set a SystemProperty of dont.expect.100.continue to true in jvm.xml , the API Gateway no longer waits for a 100-continue response on a HTTP 1.1 connection before sending a message body.
|
819438 | RDAPI-2227 | Issue: Alert filter fails to import correctly. Resolution: Previously, in Policy Studio, when you attempted to edit the imported Alert filter, the error There was a problem displaying the edit dialog null was reported.
Now, you can modify the Alert filter in Policy Studio after it is imported in a policy. |
- | RDAPI-2233 | Issue: Error when upgrading API Gateway configuration Resolution: Previously, the CertValidationOcspFilter migrate step 2 task, was incorrectly importing an incomplete version of the LoadableModule entity type. This was causing an exception when trying to upgrade the API Gateway configuration.
Now, the CertValidationOcspFilter migrate step 2 task imports a complete LoadableModule entity type. |
820584 | RDAPI-2328 | Issue: Unable to use envSettings.props certificate and environmentalized bind certificate at runtime.Resolution: Previously, in Policy Studio, it was possible to incorrectly externalize already environmentalized certificates using the Bind certificate at runtime option. Now, the Bind certificate at runtime option is removed from the certificate selector dialog for already environmentalized certificates to prevent the externalization of certificates with environment variables. |
823330 | RDAPI-2419 | Issue: Cannot access a renamed web service after it is upgraded from 6.3.1 to 7.3.0 (SP4) or 7.4.0 (SP3). Resolution: Previously, if there was an old version configuration with a renamed web service being upgraded, requests sent to the web service failed to resolve. The API Gateway was attempting to match the new web service name against the <wsdl:Service> name in the WSDL, but the WSDL still had the old name.
Now, you can upgrade a configuration with a renamed web service and requests to the web service are resolved in the new version. |
782400 | RDAPI-2461 | Issue: XML Signature Verification filter fails when request from SoapUI uses a SAML Assertion with Sender Vouches confirmation method. Resolution: Previously, API Gateway did not support generation or verification of XML Signatures using the STR-Transform for a SAML 2.0 assertion. API Gateway only supported SAML 1.0/1.1.
Now, API Gateway supports generation and verification of XML Signatures using the STR-Transform for a SAML 1.0, 1.1, and 2.0 assertions. |
821733 | RDAPI-2491 | Issue: Creating policy assembly fails with DuplicateKeysException .Resolution: Previously, when creating a policy assembly for a policy, there was a DuplicateKeysException failure.
Now, the policy assembly is successfully created. |
824834 | RDAPI-2519 | Issue: Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800). Resolution: Previously, the OpenSSL stack was subject to DROWN attack. Now, OpenSSL provides improved security and protection against DROWN attack by disabling the SSLv2 protocol by default, and removes SSLv2 EXPORT ciphers. For details see https://www.openssl.org/news/secadv/20160301.txt. |
803048 | RDAPI-2528 | Issue: Create WS-Trust Message filter does not follow the protocol. Resolution: Previously, the inserted Created and Expires elements in the RequestSecurityTokenResponse were created in the WST namespace element.
Now, the inserted Created and Expires elements in the RequestSecurityTokenResponse are created with the WSU namespace. |
820769 | RDAPI-2533 | Issue: Policy import does not recognize change to filter parameter list. Resolution: Previously, in Policy Studio, when changes were imported to the Validate REST filter, it incorrectly reported The imported configuration contains no applicable difference .
Now, changes to the Validate REST filter are correctly detected on import. |
824012 | RDAPI-2603 | Issue: HTML format request to opsdb allows XSS.Resolution: Previously, there was a vulnerability to Sec-1 Ltd for format=html vulnerability.
Now, the Admin Node Manager management interface does not support sending responses with requested traffic information in HTML format. |
- | RDAPI-2633 | Issue: In XML-Encryption, derived symmetric key not used to encrypt when it should. Resolution: Previously, the XML Encrypt filter would not always correctly encrypt a message with a derived key. Now, the XML Encrypt filter encrypts messages with a derived key as expected. |
805574 | RDAPI-2670 | Issue: Script injection into timeline on port 8090. Resolution: Previously, in API Gateway, the Monitoring API was not validating the metric group type parameter, which allowed it to return metrics data for an unknown group type. Now, the metric group type parameter is validated in the Monitoring API. The API responds with a 404 message status if the metric group type is unknown. |
827134 | RDAPI-2697 |
Issue: |
816118 | RDAPI-2809 | Issue: API Gateway becomes unresponsive after deployment failure. Resolution: Previously, the API Gateway could become unresponsive when the client ( nodemanager ) initiated deployment requests while API Gateway was serving long traffic requests at the same time. Now, if the new V_DEPLOY_INSTANCE_TIMEOUT environment variable is set, the API Gateway will timeout, report a deployment timeout error and unblock the API Gateway from serving other requests. |
827846 | RDAPI-3160 | Issue: SIGSEGV in Java_com_vordel_dwe_NativeContentSource_buffer .Resolution: Previously, API Gateway could crash when the traffic monitoring was recording transaction details for policies with the Connect To URL filter. Now, API Gateway allows traffic monitoring to record transaction details for policies with the Connect To URL filter before the related data is disposed. |
829293 | RDAPI-3171 |
Issue: Connection filters are no longer working after applying OpenSSL 1.0.1s. Resolution: Previously, API Gateway was including OpenSSL 1.0.1j-fips which has security vulnerabilities. Now, API Gateway uses OpenSSL 1.0.1s-fips, which addresses known security vulnerabilities, including DROWN (CVE-2016-0800). Important: the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available, and DH handshakes with parameters shorter than 1024 bits are now rejected. For more details, see http://openssl.org/news/secadv/20160301.txt |
The following issues are known and scheduled for correction in a future release:
Case ID | Internal ID | Description |
---|---|---|
813773 | RDAPI-1323 | In API Gateway Manager, when the logged-in user changes their password on port 8090 , they lose all their user roles. |
830624 | RDAPI-2961 | JSON Remove Node filter fails if the node to remove has a null value. |
This service pack has the following prerequisites in addition to the prerequisites specified for the main product release:
INSTALL_DIR/system/lib/modules
directory.INSTALL_DIR/apigateway/webapps/apiportal/vordel/apiportal/app/app.config
before applying API Gateway and API Manager service packs. You must then restore customized API Manager data manually in the new app.config
file.Run togglefips --disable
to turn FIPS mode off.
Start the nodemanager
to move the JARs.
Stop the nodemanager
.
Install API Gateway 7.4.0 SP 4.
Start the nodemanager
.
Stop the nodemanager
.
Run togglefips --enable
to turn FIPS on again.
Start the nodemanager
.
This section describes how to install the service pack on an existing installation of API Gateway.
To install a new API Gateway installation from scratch without an existing installation, see the API Gateway Installation Guide.
To install the service pack on your existing API Gateway 7.4.0 Core Server installation, perform the following steps:
INSTALL_DIR/ext/lib
directory (or the ext/lib
directory in an API Gateway instance). These patches have already been included in this service
pack. You do not need to copy patches from a previous version.
apigateway
directory
in your existing installation directory. For example:
tar -xzvf APIGateway_7.4.0_SP4_Core_linux-x86-64_BNYYYYMMDDn.tar.gz -C
/opt/Axway-7.4.0/apigateway/
Note
ls -l INSTALL_DIR/apigateway/posix/bin
command to view the owner of
the binaries.
To install the service pack on your existing API Gateway Analytics 7.4.0 installation, perform the following steps:
INSTALL_DIR/ext/lib
directory (or the ext/lib
directory in an API Gateway Analytics instance). These patches have already been included in this service
pack. You do not need to copy patches from a previous version.
analytics
directory within your existing API Gateway 7.4.0 installation directory. For example:
tar -xzvf APIGateway_7.4.0_SP4_Analytics_linux-x86-64_BNYYYYMMDDn.tar.gz -C
/opt/Axway-7.4.0/analytics/
Note
ls -l INSTALL_DIR/analytics/posix/bin
command to view the owner of
the binaries.
To install the service pack on your existing Policy Studio installation, perform the following steps:
INSTALL_DIR/policystudio
directory.policystudio
directory within your existing API Gateway 7.4.0 installation directory. For example:
tar -xzvf APIGateway_7.4.0_SP4_PolicyStudio_linux-x86-64_BNYYYYMMDDn.tar.gz -C
/opt/Axway-7.4.0/policystudio/
The first time you start Policy Studio, you must use policystudio -clean
.
To install the service pack on your existing Configuration Studio installation, perform the following steps:
INSTALL_DIR/configurationstudio
directory.configurationstudio
directory within your existing API Gateway 7.4.0 installation directory. For example:
tar -xzvf APIGateway_7.4.0_SP4_ConfigurationStudio_linux-x86-64_BNYYYYMMDDn.tar.gz -C
/opt/Axway-7.4.0/configurationstudio/
The first time you start Configuration Studio, you must use configurationstudio -clean
.
To allow an unprivileged user to run the API Gateway on a Linux system, perform the following steps:
INSTALL_DIR/system/conf/jvm.xml
file: <VMArg
name="-Djava.library.path=$VDISTDIR/$DISTRIBUTION/jre/lib/amd64/server:
$VDISTDIR/$DISTRIBUTION/jre/lib/amd64:$VDISTDIR/$DISTRIBUTION/lib/engines:
$VDISTDIR/ext/$DISTRIBUTION/lib:$VDISTDIR/ext/lib:
$VDISTDIR/$DISTRIBUTION/jre/lib:system/lib:$VDISTDIR/$DISTRIBUTION/lib"/>
<VMArg
name="-Djava.library.path=$VDISTDIR/$DISTRIBUTION/jre/lib/i386/server:
$VDISTDIR/$DISTRIBUTION/jre/lib/i386:$VDISTDIR/$DISTRIBUTION/lib/engines:
$VDISTDIR/ext/$DISTRIBUTION/lib:$VDISTDIR/ext/lib:
$VDISTDIR/$DISTRIBUTION/jre/lib:system/lib:$VDISTDIR/$DISTRIBUTION/lib"/>
setcap 'cap_net_bind_service=+ep'
INSTALL_DIR/platform/bin/vshell
to allow the API Gateway to listen on privileged ports.
It is not necessary to perform these steps on an API Gateway Appliance.
Go to Axway Sphere at https://support.axway.com to find all documentation for this product version.
For information about how API Gateway is used in Axway 5 Suite, refer to:
All Axway documentation is available from Axway Sphere at https://support.axway.com.
The Axway Global Support team provides worldwide 24 x 7 support for customers with active support agreements.
Email support@axway.com or visit Axway Sphere at https://support.axway.com.
Copyright © 2016 Axway. All rights reserved