Upgrading from 11.0.X to 11.1.0#

SDK#

Changes to BackchannelAuthenticationRequest for CIBA plugins#

Version 11.1.0 adds support for the login_hint_token and id_token_hint parameters in CIBA requests. For that, it introduces a type-safe BackchannelHint sealed interface to represent all three CIBA hint types.

Changed: getSubject() can now return an empty string#

BackchannelAuthenticationRequest.getSubject() now returns an empty string when the hint is a login_hint_token, since no subject can be derived from an opaque token without further processing by the authenticator. It returns the subject string for login_hint and id_token_hint.

New: getHint() returns BackchannelHint#

A new getHint() method returns a BackchannelHint — a sealed interface with three record types that directly encode which hint parameter was provided:

• BackchannelHint.LoginHint(String subject) — a login_hint value
• BackchannelHint.IdTokenHint(String subject) — the subject extracted from a validated id_token_hint
• BackchannelHint.LoginHintToken(String token) — an opaque login_hint_token, passed through as-is

Use of getHint() should be preferred to the use of getSubject().

How to update your plugin#

When possible, replace any usage of getSubject() with a pattern-matching switch on getHint(). Return failure if your plugin doesn’t support opaque tokens (login_hint_token).

Refer to the Back-Channel Authenticator Plugin documentation for full details.

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).