Upgrading from 10.0.X to 10.1.0#

Passkeys and WebAuthn Authenticators#

New templates were added to the Passkeys and WebAuthn authenticators to provide the new functionality for allowing users to set an alias for their newly registered devices. The new templates are:

• authenticator/passkeys/register/set-alias/get.vm
• authenticator/webauthn/register/set-alias/get.vm

New messages were added as well (at the same paths as the templates), to provide the necessary translations.

HTTP Server Header Size Limit#

The HTTP Server was updated to enforce HTTP header size limits more strictly. This means that it is possible that workloads that previously worked will now start failing with Response Header Fields Too Large.

If you see this error, you may need to increase the limit by setting the se.curity:identity-server:max-header-size system property to a value above 65536, which is the default limit.

OAuth Client Basic HTTP Authentication - URL decoding of client secret#

Since version 10.0, the server does URL decoding of both the userid and the password components to establish the client ID and secret for validation. This aligns with OAuth 2.0, which states that clients should encode their ID/secret in this context.

That change can be breaking in cases where a client’s secret includes escape sequences (e.g. %3A and +), but the client doesn’t URL-encode the secret in the Authorization header. To avoid blocking server upgrades in such cases, the se.curity:identity-server:authorize:allow-unencoded-client-secret-on-basic-auth system property was added. If the property is set to true, the server also checks the client secret without URL-decoding it, as a fallback.

That property is meant to allow a transition period on edge-case scenarios and it will be removed in a future major release. Clients should be updated as soon as possible, in any case.

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