Critical changes in this release

This topic highlights changes that are made that might impact backward compatibility in IBM Security Verify Access version 10.0.4.

Verify Access Platform

  • CPU alerts

    CPU alert notifications are now only raised if the CPU threshold is exceeded for an extended period of time. A single alert will now be raised when the threshold is exceeded, rather than raising a new alert each time the CPU utilization changes.

  • Management Authorization
    The REST APIs for Management Authorization now list the in-built admin account within the "Full Write" role. Previously the admin account was not shown in any Management Authorization APIs.
    Note: This is a cosmetic change. The in-built admin account is a fixed member of the "Full Write" role and has always had access to all APIs and features.
  • WebSEAL management template files

    The default WebSEAL management template files (for example: login.html) have been updated so that embedded images, styles and scripts are now located in separate files. This does not impact existing WebSEAL instances which are upgraded to the latest version but impacts any new WebSEAL instances which are created. See Web server response configuration.

  • WebSEAL cookie attributes

    The cookie attributes that are defined in the [cookie-attributes] stanza are now applied to the IV_JCT cookie. In the past, these attributes did not impact the creation of this cookie.

  • OAuth EAS

    By default, the OAuth EAS no longer accepts the authentication token from the query string. See allow-query-string-token.

  • Docker image

    The verify-access Docker image can now only be started as a configuration container. If you attempt to start this image with the SERVICE environment variable set to runtime, webseal, or dsc, the container will display an error message and then stop. See Docker Image for Security Verify Access.

  • Amazon Web Services (AWS)
    • The IBM Security Verify Access image available in the AWS Marketplace is now available for the current generation instance types.
    • From version 10.0.4 onwards, the Verify Access image is only available to deploy on the current generation instances which are powered by the AWS Nitro System hypervisor.
    • Existing virtual machines that are running on the previous generation instances can be still be upgraded to the current version. However new deployments from the marketplace are only available for the new instance types.
  • The Web Proxy API Access Control configuration screens, within the Web console, are no longer available in a 'restricted' cluster node.
  • Local Management Interfaces Web Services Interfaces
    JSON payloads in web services requests to the local management interface are now subject to stricter JSON validation than past versions of Verify Access. The following changes in behaviour might be observed:
    • JSON payloads must now be correctly encoded, and incorrect or invalid JSON data are no longer accepted.

      For example, if a JSON payload contains invalid escape sequences like \*, it is no longer accepted. To supply the sequence \* correctly, escape the \character: \\*.

    • In some cases, a JSON array containing a single string element would previously have been interpreted as if it were a JSON string. Verify Access now always correctly handles single element JSON arrays as arrays.

      For example, {"key":["value"]} was often interpreted as being equivalent to {"key":"value"}. Review the web services API to ensure your JSON payload contains the correct format.

  • Java support for the PDJRTE

    The downloads area of the appliance now contains the PDJRTE distribution from the v10.0.2.0 release of IBM Security Verify Access. This version of the PDJRTE supports IBM Java. The PDJRTE does not currently support OpenJDK.

  • WebSEAL static server response pages

    HTTP Status Code 503 is used when returning the "Third-party server not responding" response page 38cf04d7.html. Previously HTTP Status code 500 was used. See Static server response pages.

Advanced Access Control (AAC)

  • UserLookupHelper update

    The UserLookupHelper previously ignores override properties when caching the configuration for init calls that use the Verify Access RTE, or the configuration in the Username Password authentication mechanism. This results in old override properties being returned via the cache, instead of the new properties taking precedence. The UserLookupHelper will now cache based on override properties as well for init calls that use the Verify Access RTE, or the configuration in the Username Password authentication mechanism.

  • Out of the box authentication policies disabled by default

    From IBM Security Verify Access version 10.0.4, all predefined policies are disabled by default for fresh installations. On upgrade, only new predefined policies are disabled by default. Existing policies will not have their enabled status changed on upgrade.

  • Password Vault

    The Password Vault API is now updated to match the functionality supported by the IBM Security Verify Password Vault. The POST and PUT HTTP methods are updated to support both creating and updating credentials. The HTTP status code returned by POST request is now changed from 201 CREATE to 200 OK. See Configuring Password Vault.

  • New Template Files directories

    Two new directories, css and scripts, have been added to the static directory in Template Files to ensure the default templates are content security policy compliant. These directories will appear on upgrade as well as a fresh install. See Template Files Format.

  • Apple Push Notification Provider timeout

    The Apple Push Notification Provider previously had no connect or response timeout configuration set when requesting a push notification to be sent, which meant that a user may experience a timeout of up to 3 minutes when performing MMFA. Now the connect timeout and response timeout have both been set to 10 seconds, in line with other supported push providers.

  • Deprecated IBM Security Verify APIs have been removed
    IBM Security Verify APIs that begin with /v1.0/authnmethods have been removed following their previous deprecation. As a result, any CiClient methods that rely on those APIs, that were previously marked as deprecated, will no longer work.
    • CiClient.getAuthMethods
    • CiClient.getSignatureAuthMethods
    • CiClient.getAuthMethod
    • CiClient.enrollAuthMethod
    • CiClient.updateAuthMethod
    • CiClient.deleteAuthMethod
    • CiClient.getValidation
    • CiClient.validateOTP
    • CiClient.createVerification
    • CiClient.createTransientVerification
    • CiClient.getVerifications
    • CiClient.getVerification
    • CiClient.verifyTOTP
    • CiClient.verifyOTP
    • CiClient.verifyTransientOTP

Federation

  • Dynamic client registration updates

    Previously the dynamic client registration status code for a successful registration is 200, but the specification mandates a 201. Currently, the dynamic client registration returns a 201 status code for a successful registration to ensure compliance with specifications. See Dynamic client registration.

    For dynamic client registration requests, if the access token that is provided is expired, revoked, malformed, or invalid for other reasons, the status code returns a 401. It previously returned 403. See RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage.

  • Device code flow update

    In device code flow, when the code belongs to a different client from the request, an invalid_grant exception is thrown. This adheres to: RFC 6749 - The OAuth 2.0 Authorization Framework