Strange. We have a test for this:
Are you doing anything in particular that this test does not?
Thank you for getting back to me and for the link to the test case. It is good to confirm it should be working, with an example, and that the problem must be something we're doing.
We have a custom form authentication mechanism which is no doubt the problem. It is pretty much the ServletFormAuthenticationMechanism and FormAuthenticationMechanism out of undertow core with a few tweaks to return a json response if the Accept header for appliction/json is set.
It shouldn't block other Authentication Mechanisms (CachedAuthenticatedSessionMechanism is hit but doesn't find the AuthenticatedSession), and does set cachingRequired true when it calls AuthenticationComplete etc. The AuthenticatedSession is added to the session locally, but does not get replicated which is odd as other attributes are replicated. We must be missing something, perhaps something wraps one of those classes we based this on adding functionality required for replication that we're now missing.
I just confirmed that if I use <auth-method>FORM</auth-method> it works as expected, so it is definitely our custom authentication mechanism.
Found the actual problem if anyone encounters this.
It must check the authentication mechanism type from the name before replicating the AuthenticatedSession. I changed the custom mechanism 'name' variable to be "FORM", as it would be in the default form mechanism and it is now working.
Really, we should be treating custom authentication mechanisms the same way we treat FORM authentication.