Upgrading from 10.2.X to 10.3.0#

JSON / REST Data Source - Attribute Access#

The attribute data access feature of the JSON data source was updated to support sending additional parameters (parameter-mappings) to the backend even when the subject is provided in the URL path (url-path option).

In previous versions, parameters were only sent when the subject was provided by other means (e.g. query parameters); when using url-path any configured parameter-mappings were ignored. The Admin UI didn’t allow configuring parameter-mappings when using url-path, but it was still possible to configure them via the CLI or XML configuration, even if they were ignored.

In the unlikely case that you have configured parameter-mappings with url-path (previously ignored), note that those parameters will now be considered and included in the request to the backend. Refer to JSON / REST Data Source for details on the exact behavior.

UI Kit Updates#

Symbols#

In version 10.3.0, we’ve refreshed the symbols on the login pages to better align with our current UI design style. These assets had not been updated since version 7.0.

Note: If you need to revert to the previous symbols for any reason, they can still be found in the UI-Kit repo inside the src/identity-server/images_legacy directory.

BankID Accessibility Improvements#

In July 2025, new legal requirements for the digital accessibility of products and services will come into effect. These regulations are designed to ensure that digital solutions are inclusive and usable for all individuals, including people with disabilities.

BankID templates have been updated to improve the accessibility and usability of QR codes.

Updated Templates#

• authenticator/bankid/launch/index.vm
• consentor/bankid-signing-consentor/bankid-poller.vm

Serialization filter system property#

The se.curity:identity-server:serialFilter Java system property allows additional Java types to be deserialized, on top of the types the Curity Identity Server allows by default. In previous versions, setting this property did not work correctly: instead of only allowing the types matched by its patterns, it effectively disabled the restriction for every type not in the default allow-list. This was fixed in versions 11.4.3, 11.3.3, 11.2.4, 11.1.4, 11.0.6, 10.7.8, 10.6.6, 10.5.5, 10.4.7, 10.3.5, 10.2.6, 10.1.5 and 10.0.7.

From these versions, only the types matched by the property’s patterns are allowed in addition to the default ones, and any other type is rejected. Deployments that set this property must review its value and make sure that it matches every type that actually needs to be deserialized, as a value that is too narrow previously went unnoticed. A type rejected by the filter is logged as a warning (Type ... not allowed to be deserialized).