On 3/24/15 7:38 PM, arjan tijms wrote:
> Hi,
>
> On Tue, Mar 24, 2015 at 11:01 PM, Ron Monzillo
> <ron.monzillo_at_oracle.com <mailto: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.
>
Hi Arjun,
I may not be understanding you, but I suspect that implementations that
are creating a new CBH, are using CBH (and SAM) instantiation as a way
to isolate the processing done for one request, from that done for
another request. I assume that such considerations are more important if
the CBH has some statefulness to it. For example, I have seen some
container CBH's that have been implemented such that the effect of
handling a CallerPrincipalCallback, is not applied/committed till after
the return from validateRequest. Clearly there are more efficient ways
to implement the CBH, but in some cases, the container infrastructure
requires or at least inspires more complicated approaches.
IMV, What is important, is that the SAM implementer know that it must be
prepared to operate correctly in a container that will be able to issue
multiple concurrent invocations to the SAM; in which case the SAM needs
to be able to disambiguate and separate any internal state that it keeps
to process the authentication dialogs; Conversely it is the container's
responsibility to ensure that there is no interference within the
CallBackHandler(s).
> 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.
And the container cannot assume that a new SAM will be instantiated for
every invocation, because it is the AuthContext implementation, not the
container that is responsible for the instantiation an initalization of
SAM's. Tthe AuthContext implementation is encapsulated with
the pluggable AuthConfigProvider, and as such the container can not
assume a per request SAM instantiation model
>
> 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;
>
A SAM does need to be prepared ro process concurrent requests, as does a
CBH. Did I suggest something different?
>
> 1. SAMs are created once (possibly before a request happens) and
> initialized with a callback handler
>
yes
> 2. SAMs can be reused (and when reused do not have to be reinitialized
> all the time with a new callback handler)
>
yes, they only need to be initialized once, with the arguments as
defined by the initialize method
> 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)
>
I don't agree with 3.
HTH,
Ron
>
> 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
>>>
>>>
>>>
>>
>>
>
>