Skip to content

Fortified IDDocs

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.

Review these configuration and deployment changes before upgrading Fortified ID Access.

SAML IdP lists without target SPs are rejected

Section titled “SAML IdP lists without target SPs are rejected”

A nonempty IdP assertion_config list that contains no target_sp values, such as [{}] or [{"target_sp": []}], now fails IdP initialization. It is not treated as an empty list and does not enable metadata fallback.

If you intend to keep an explicit SP allowlist, configure the intended target_sp values. If you intend to trust the loaded, filtered SP metadata, omit the list or set it to [] after reviewing the trusted entities and application/profile settings. See SAML IdP.

Existing valid lists, including wildcard entries, keep their behavior and require no migration for this change.

Multi-node clusters require a full restart

Section titled “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:

  1. Stop all Access nodes in the cluster.
  2. Upgrade every node to the new Access version.
  3. 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.

Include directives used as array elements are flattened

Section titled “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

Section titled “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.

SAML application app_tag overrides SAML profile app_tag

Section titled “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 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

Section titled “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.

Selector authenticator must have a label configured on every option.

New parameter: use_generic_error_page (default: false)

Section titled “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.

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.

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

"app_profile" : "@include:samlprofile/"

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 ([""]).

Ensure to adapt if used in environment.

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

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

Section titled “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

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,