Hi,
On Tue, Mar 24, 2015 at 11:01 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> no, a single server auth module does need to be able to process concurrent
> requests.
>
Okay ;)
Yes the callback handler is expected to be thread safe. I don't know if
> that is ever stated as a requirement, but it must be the
case, unless the encompassing container knows it is somehow serializing its
> calls to validateRequest, such that the CBH it gives
> to a module will never be concurrently invoked.
>
Hmmmm, I've seen in at least one case (an older Java EE 6 implementation
that's still in active user however) that the runtime created a new
callback handler for each request, which then simply collected the data
from the CallerPrincipalCallback and GroupPrincipalCallback in instance
variables. This data was retrieved from that callback handler after
validateRequest returned and then processed. Clearly this one was not
thread-safe.
However, I just checked the latest implementation of that same runtime and
they now collect the data in thread local storage, which means it's
thread-safe.
What sometimes happens as well I noticed is that a runtime creates new
instances of the server auth config, auth context and specifically auth
module every time validateRequest or secureResponse needs to be called (so
normally at least twice per request), and then calls the initialize()
method on the auth module with a new instance of the callback handler, even
when that handler is thread-safe.
Obviously, when the runtime creates new instances for everything all the
time it can also seemingly get away with a non thread-safe handler.
However, since this server auth config and auth context can also be
implemented by application code from within the application archive, this
wouldn't necessarily work for that code.
Summarizing; to put "single sam doesn't need to processes concurrent
requests" and "callback handler must be thread safe" together, would it
then be the intention (more of less) that;
1. SAMs are created once (possibly before a request happens) and
initialized with a callback handler
2. SAMs can be reused (and when reused do not have to be reinitialized all
the time with a new callback handler)
3. When a SAM instance is reused, only one client should use it at the same
time (e.g. by removing a SAM instance from a pool and returning it to that
after calling a method on it returns)
Is that correct?
Kind regards,
Arjan Tijms
>
>
> Ron
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> The intent of this area of
> the spec being that a module author must recognize that the module may be
> involved in the simultaneous processing of
> multiple authentication dialogs, and the module needs to be able to
> diambiguate the dialogs any any related state kept within
> the module (e.g. a saved initial request that will be redirected to when
> authentication completes)
>
> HTH, and please continue the discussion if need be,
>
> Ron
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>