On 3/24/15 12:26 PM, arjan tijms wrote:
> p.s.
>
> Just after sending the above mail, I realized
> that ServerAuthConfig#getAuthContextID gets passed in a MessageInfo
> instance. I have to double check the spec, but if this is guaranteed
> to be called before ServerAuthConfig#getAuthContext is called then the
> ServerAuthConfig could store this and pass it on to the ServerAuthContext.
>
> Is this indeed what is supposed to be done?
>
Hi Arjan,
Sorry of you get 2 versions of my response.
ServerAuthConfig#getAuthContextID is not required to be called with every
MessageInfo, prior to a call to ServerAuthConfig#getAuthContext.
The spec says
> 3.7.1 Authentication Context Identifiers
>
> This profile does NOT impose any profile specific requirements on
> authentication context identifiers. As defined in Section 2.1.3,
> “Acquire AuthContext Identifier,” on page 17, the authentication
> context identifier used in the call to getAuthContext must be
> equivalent to the value that would be acquired by calling
> getAuthContextID with the MessageInfo that will be used in the call to
> validateRequest.
Moreover, the call to getAuthContext doesn't have to be made on every
request; although it is typically simpler to make the call, than
to figure out if none of the arguments to the call have changed.
> 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.
>
>
> On Tue, Mar 24, 2015 at 5:09 PM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> I had another question about JASPIC.
>
> The Javadoc of ServerAuthModule says the following:
>
> " [...] A module should also assume
> * it may be used concurrently by multiple callers. It is the module
> * implementation's responsibility to properly save and restore
> any state
> * as necessary. A module that does not need to do so
> * may remain completely stateless. [...]"
>
> However, the interface also declares the initalize method with the
> following signature:
>
> void initialize(MessagePolicy requestPolicy,
> MessagePolicy responsePolicy,
> CallbackHandler handler,
> Map options)
>
> What I don't entirely understand here is how the module can either
> be completely stateless or save to be called concurrently by
> multiple callers, when it has to store at least the handler somewhere.
>
> I could imagine the module saving the handler in an appropriate
> context (e.g. for the Servlet Profile this could be the request
> scope), but the initialize method does not have access to any such
> context (presumably made available via MessageInfo).
>
> A similar story holds for the ServerAuthContext, which also has
> the requirement to support concurrent access, but doesn't have
> access to any context either.
>
> Here neither AuthConfigProvider.getServerAuthConfig
> and ServerAuthConfig#getAuthContext are passed in any context
> (MessageInfo).
>
> Any clarification here would be greatly appreciated.
>
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. 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
>
>
>