On 3/24/15 5:49 PM, arjan tijms wrote:
> Hi,
>
> On Tue, Mar 24, 2015 at 8:04 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto:ron.monzillo_at_oracle.com>> wrote:
>
> This concept of stateful and stateless ness is referring to the
> concurrent processing of multi-state authentication dialogs;
> where the module must be able to process each incoming request
> against the proper state for the dialog of which the
> request is a part. Foy example a completely stateless module (in
> this regard), might keep all such state in cookies, so
> that it can easily determine the state in which the current
> request is to be processed. Another more stateful module, might
> store authentication dialog state in a session, which it would
> gain access to via a session cookie.
>
>
> Thanks for the clarification. So, if I understand correctly it's not
> about instance variables of the server auth module, is it?
>
> The text sounded quite similar to that of a Servlet (e.g. HttpServlet):
>
> "Servlets typically run on multithreaded servers, so be aware that a
> servlet must handle concurrent requests and be careful to synchronize
> access to shared resources. Shared resources include in-memory data
> such as instance or class variables and external objects such as
> files, database connections, and network connections"
>
> In case of Servlets it's well known that a single instance of a
> Servlet services multiple clients (threads) and therefor instance
> variables have to be thread-safe.
>
> But in the case of a server auth module it's not suggested that a
> single class instance of that should be reused for multiple requests,
> right?
no, a single server auth module does need to be able to process
concurrent requests.
>
> I'm still doubting a little whether that is or is not the case because
> of this:
>
> Once an authentication context is acquired, it may be reused to
> process subsequent requests of the application for which an
> equivalent authentication context identifier, Subject, and
> properties Map (as used in the getAuthContext) applies. Runtimes
> that wish to be dynamic with respect to changes in context
> configuration should call getAuthContext for every request.
> FWIW, this wording was chosen to make it possible minimize the
> performance impact of the 196 spi calls.
>
>
> So an authentication context may be reused, but then the runtime that
> does this reusing somehow has to pass the new CallbackHandler instance
> in for a specific request and make sure that same authentication
> context instance is not used for concurrent requests?
>
> Or is the CallbackHandler supposed to be thread-safe and reusable
> itself by multiple (concurrent or not) requests?
>
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.
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
>>
>>
>>
>
>