Breaking changes

Here we address changes that may cause previously working configurations to stop working after the update, if they are not adjusted to handle the changes below.

3.9.1

Multi-node clusters require a full restart

Access now uses upgraded Hazelcast, 5.6. Hazelcast members using older versions cannot run together in the same cluster. A rolling upgrade, where one Access node is upgraded while the other nodes keep running on the previous version, is therefore not supported.

When upgrading a multi-node installation:

Stop all Access nodes in the cluster.
Upgrade every node to the new Access version.
Start the nodes again after all nodes have been upgraded.

The same restriction applies when rolling back: stop the complete cluster and restore the same Access version on every node before restarting it.

3.8.0

Include directives used as array elements are flattened

When an @include directive is used as an element inside a JSON array and the included file contains an array, the included elements are flattened into the parent array.

Use @include_as_array when the included array should remain nested as one array element.

OIDC signing-key configuration is more flexible

OIDC signing-key handling now supports overlapping sign_ref configurations and runtime key selection.

Access still fails startup when the configured signing-key material cannot be resolved from the supplied keystore configuration, for example because of a bad alias, wrong password, or missing private key.

At the same time, startup no longer fails only because configured certificates are expired or future-dated. In those situations Access can still start and fall back to the first configured signing key.

3.7.0

SAML application `app_tag` overrides SAML profile `app_tag`

SAML applications can now define app_tag on application level. If both the SAML application and the selected SAML profile define app_tag, the application value takes precedence.

Review configurations where app_tag may already be present on SAML applications. Those applications may now select authentication methods based on the application value instead of the profile value.

cancel_location inheritance removed

cancel_location is no longer inherited from parent authenticators to child authenticators. Environments where child authenticators relied on an inherited cancel_location must configure the value explicitly on each authenticator.

LdapClient – `use_schema` default changed to `false`

The default value of use_schema in the LdapClient module has changed from true to false. This improves LDAP query performance in most environments. If your environment requires schema-aware queries, set "use_schema": true explicitly in your configuration.

3.5.0

Authenticator

Selector authenticator must have a label configured on every option.

3.4.0 OIDC

New parameter: use_generic_error_page (default: false)

A new configuration parameter, use_generic_error_page, has been introduced. It applies to authentication errors that cannot be mapped to a configured failed_redirect and where fail_location is not set.

• false (default): The authenticator propagates the error to the underlying framework, allowing OIDC/SAML to handle the error according to their default behavior.

• true: Restores the previous behavior, where a generic error page is displayed by the authenticator.

This change makes error handling more explicit and aligns the default behavior with the surrounding authentication framework.

3.3.0

OIDC keystore

A single password is now used for both the key and the store.Only PKCS#12 (.p12) format is supported, and the store must contain exactly one alias.The .p12 file is selected from known resources — global stores are not recommended.

SAML Profile

The SAML-module have to be updated with the following configuration in order to support SAML profiles.

"app_profile" : "@include:samlprofile/"

3.2.2

The LDAP search valve has been updated to better handle single vs. multi-value attributes. In previous versions, all returned values were treated as multi-value attributes, even when only a single value was present, which made configuration unnecessarily complex. With this update, attributes containing a single value are now returned as a simple value ("") instead of an array ([""]).

Impersonate has updated configuration

Ensure to adapt if used in environment.

3.1.0

Updated default encryption

As of 3.1.0 default encryption has been changed. This will only affect systems where encryption is enabled.

To keep previous implementation ensure environment setting:

FORTIFIED_SECRETS_IMPL = local

3.0.0

SAML NameID format update

When deciding outgoing SAML assertion NameID format selection process is updated. If NameID format is configured this will supersed anything else. If not configured, requested format value from the AuthNRequest is used.

If none of the above is true, default fallback is:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Any format values in SAML meta data is ignored.

Overriding logos has new way of configuration

Default property names, and the overriding, of logos have changed.

All logos are now configured in a "logos" property in the ui_config and ui_config_overrides.json

{
  "logos": {
    "app_logo": {
      "src": "assets/fortified_logo_green-white.svg",
      "height": "40px"
    },
    "access_header": {
      "src": "assets/fortified_logo_green-teal.svg",
      "height": "80px"
    },
    "access_footer": {
      "src": "assets/fortified_logo_green-teal.svg",
      "height": "40px",
      "link": {
        "url": "https://fortifiedid.se",
        "text": "FortifiedID"
      }
    }
  }
}

All Integrity Access ui's now use logos defined in the access_header and access_footer. All apps with a top header bar (Password Reset, Portal etc) use the app_logo.

This allows for better separation of logos and for using the same configuration and/or same configuration file for multiple ui apps.

For more information about new configuration possibilities, see UI Configuration Overrides

New Hazel cast schema

If running cluster, update cluster configuration xml file using schema:

http://www.hazelcast.com/schema/config/hazelcast-config-5.3.xsd

All session cookies now are set out to require User-Agent communication being done using TLS (encrypted channel)

Running in a non secure channel will require setting:

"http_session_cookie_secure": false,