SecurityContext incompatible with older versions

[markusheiden]

Describe the bug
Spring Session cannot handle Spring Boot 2.3 and 2.4 sessions in parallel, because the serialization of SecurityContextImpl is whether backward nor forward compatible:

java.io.InvalidClassException: org.springframework.security.core.context.SecurityContextImpl; local class incompatible: stream classdesc serialVersionUID = 540, local class serialVersionUID = 530

This makes it impossible to migrate from Spring Boot 2.3 to 2.4 without downtimes.

To Reproduce
Use Spring Session (e.g. Redis) to share sessions between Spring Boot 2.3 and 2.4. applications.

Expected behavior
No serialization failures. 2.3 sessions can be handled by 2.4 and vice versa.

[eleftherias]

Thanks for the report @markusheiden.

Spring Security is not intended to be serialized between versions. See #1945 for the explanation.

There are some suggestions on how this might work in the future in #3737.

To mitigate this, you can invalidate the sessions, which will let users get a new one.

You can also switch to Jackson serialization to avoid this issue in future version upgrades. See #3736

[markusheiden]

It is hard to find documentation for the JSON serialization.

An example is linked in https://docs.spring.io/spring-session/docs/current/reference/html5/#samples

[markusheiden]

LDAP JSON support is missing.

See #9263

[markusheiden]

Session invalidation is no solution, when using rolling updates or canary deployments. The sessions (of two versions of Spring Security) have to co-exist for that with backward and forward compatibility. Currently there is no good solution to this problem, because the above mentioned JSON support in not well documented and incomplete.

The only solution in this scenario is to use session pinning, so that the users just have to re-login once. But session pinning is considered an anti pattern for scalability.

But anyway: Thanks for the pointer to the JSON support! :-)

[kramer]

@eleftherias

To mitigate this, you can invalidate the sessions, which will let users get a new one.

What would be the correct way to do that programmatically since all removal/expiry related methods in RedisIndexedSessionRepository rely on loading the session?