[CVE-2020-1732] Adjust JASPIC integration to create a new ServerAuthModule for each request.

[darranl]

No description provided.

[arjantijms]

This is a somewhat older issue, but I got some questions about it recently so would like to add a link to the upstream PR and specifically the discussion there:

eclipse-ee4j#270

In short, this is not necessarily a CVE in Soteria itself, but rather in the combination of how WildFly/Elytron integrated it.

When using the Subject for the request state and considering the callback handler to be either stateless or containing only threadsafe global data, there is no vulnarability.

@darranl and @fjuma How do you handle this in current versions of WildFly? Do you repatch Soteria for every release (since we never merged the original PR), or did you remove the usage of request state from your callback handler?

See also the following recommendation in the specification text:

https://jakarta.ee/specifications/authentication/3.1/jakarta-authentication-spec-3.1#state

(I know it's a SHOULD, maybe we can upgrade this to MUST?)

[darranl]

Hi @arjantijms we have compensated for the Soteria implementation by switching to a CallbackHandler that moves the state to a ThreadLocal allowing the request specific state to be accessed from the current thread whilst a common CallbackHandler instance is in use.

[arjantijms]

@darranl thanks, that's interesting to hear.

Do we need to retract the CVE? As currently I guess all versions of Soteria would still be flagged, and that would affect WildFly and JBoss too in scanners such a Sonatype?