Luke Taylor (Migrated from SEC-1314) said:
This functionality adds a lot of unnecessary complication to the implementation and in both cases there are cleaner alternatives. The context maintenance classes are crucial to the framework so the simpler we can keep them the better.
The use of a different SecurityContext implementation is now supported through the SecurityContextHolderStrategy.createEmptyContext() method, making the securityContextClass property redundant.
A better alternative to cloning would be to override the loadContext() method and copy the default context it creates. Since the Authentication should be considered to be immutable, something like:
SecurityContext context = SecurityContextHolder.createEmptyContext();
Axel Mendoza Pupo said:
The securityContextClass property in the plain old HttpSessionContextIntegrationFilter is a good way to change the default implementation of the security context. The new way involve the reimplementation of a filter or one of the related classes to get configured the new security context to be used to the authentication process or to store whatever we want to save on the http session in a fashion way. I think the property should be undeprecated and used by default without the need to create an empty context in the SecurityContextHolder who delegate in the obtained SecurityContextHolderStrategy (where I can change the strategy?, through system properties?), to create a handCoded object of SecurityContextImpl (I mean that the securityContextClass not configured).
The old way work, but it's marked as deprecated.
My vote is for the undeprecated securityContextClass property return