I've been having an issue regarding JBoss spreading the login process over multiple threads (from what I can see), and as a result some thread local storage (TLS) data I save while the first thread is active, then causes me to not be authenticated when the second thread takes over (since it is no longer on that thread).
I've had to implement a client authentication single-sign (SSO) on mechanism for a project I'm working on, and due to a customer requirement, all clients must share the same client certificate, so I can't use the certificate to gain username details. I've worked around this by adding the encrypted username as an attribute in the URL, then decoded this and stored it in TLS using a Valve. Then when JAAS rolls around, I just look in this TLS store and retrieve my username. Now, this has worked fine, and without any issue, until it turns out that some components still need to be username/password authenticated, regardless of the SSO status.
Now, again, I've worked around this by modifying the security domain on the ejb-jars to use the old authentication method (a custom LDAP login module, by the way) and during this authentication process, set up the TLS stores and the like, to mimic the effect of actually having logged using a certificate. This works 95% of the time, but every now and them I can see the TLS store is empty when the callback goes to retrieve the username, and I notice that it is being handled by two separate threads, which would explain why.
My question is - I'm not very sure about the multi-threaded nature of the JBoss/JAAS login process (I always assumed it was a single login thread, indeed, maybe it is and what I'm seeing is related to something else) but does this issue sound familar to anyone, or are there any resources or advice anyone can lend to me?