Add Jackson Support for Objects stored in HttpSession

[rwinch]

It would be nice to provide custom serialization mechanism that uses Jackson for objects Spring Security places in session. This would make serializing much faster and ensure consistency when using things like Spring Session. Some of the interfaces (and classes) are:

• SecurityContext (SecurityContextImpl)
• Authentication (various implementations of it)
• UserDetails (User)
• CsrfToken (DefaultCsrfToken)
• SavedRequest (DefaultSavedRequest)

We might also try to provide compression on the serialization. For example when UserDetails is the principal of an Authentication, we can derive a UsernamePasswordAuthenticationToken from the UserDetails and assume SecurityContextImpl is used.

UPDATE spring-projects/spring-session#434 has must of the support we would need for this feature. We may want to merge those changes into Spring Security

[jeetmp3]

@rwinch as per my understanding, you want put serialized SecurityContext into session. i. e. Instead of storing whole SecurityContext object, a serialized json string will be stored in session. Please correct me if my understanding is wrong.

[rwinch]

@jeetmp3 Thanks for reaching out! For now I would focus on ensuring we can serialize and deserialize any Spring Security objects that go into session with Jackson. This will help enable users to write hooks to serialize Spring Security with JSON. After that we can add hooks in Spring Security that uses the the serialization mechanisms.

[jeetmp3]

@rwinch For now only mix-in classes for Spring Security objects will be added right ?

[rwinch]

@jeetmp3 Correct. Pretty much the work you have already done in the Spring Session Sample you added.

[jeetmp3]

@rwinch let me know when you verified those sample mixins, so that i can start adding those mixins classes into security.
PS Is there any specific package/module to add mix-ins?

[rwinch]

Once again thank you for your contribution. I was able to verify the mixins and they look pretty good from my perspective.

• Rather than having DummyServletRequest we should probably modify DefaultSavedRequest to support being built (perhaps using a builder) without the HttpServletRequest object. This should also allow removal of DummyHttpSession.
• Some updates for the tests
  ** I'd change the tests to be a little more exact. Perhaps you can use something like JSONassert.
  ** We should have tests that verify the exact output of serializing each of the types. This will ensure that we do not change the way the objects are written
  ** We should have tests that verify the result of deserializing each objects
  ** You will need to use assertj to get the checkstyle to passs

[jeetmp3]

@rwinch thanks for the feedback! I'll start working on tests. Other then DefaultSavedRequest there is another class WebAuthenticationDetails which also use HttpServletRequest. I think we should also consider to modify this class too.

[jeetmp3]

@rwinch I've updated all the tests. Should we start merging these mix-ins into spring-security?

[rwinch]

@jeetmp3 Thanks for the response! Yes I think we should try and get a separate Pull Request open for merging the Mixins. Thanks again for all your efforts with this :)

[jeetmp3]

@rwinch thanks for the quick response! Just wants to confirm, should i add these mix-ins in one specific module or in target class specific module ?

[rwinch]

Here are my thoughts, but feedback welcome.

We should add them to the module that the class they serialize belongs to. For example DefaultCsrfTokenMixin would go into spring-security-web because that is where DefaultCsrfToken is.

I would place them within a package named base-package.jackson. For example, DefaultCsrfTokenMixin would be placed in org.springframework.security.web.jackson2 because the base package for spring-security-web is org.springframework.security.web.