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,
The call to getAuthContext requires an AuthContextID, and the
authContextID could have been obtained by calling getAuthContextID on the
ServerAuthConfig (and with the current MessageInfo), but the spec also
allows for the case, where the runtime uses a previously determined
authContextID value in the call to getAuthContext; so no I don't think
it is safe to assume that the AuthContextID is in the MessageInfo.
> 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.
>
>
> 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.
>
This part of the spec was referring to modules that orchestrate multi-state
authentication dialogs, where the focus is on the various states of the
authentication dialog, and
that a module must be able to support multiple concurrent instances of
such dialogs, where each
dialog may have progressed to a different state, and where each incoming
message must be
processed as part of the proper dialog and within the proper state of
that dialog.
A stateless module might find all the data it needs to determine the
current state of the dialog,
etc. in things like cookies accompanying the requests. Stateful modules,
may try to store the
current state of in progress dialogs, which they would then restore for
their processing of the
incoming request. Modules that use session cookies to link up to stored
dialog and or session
state would be more of the stateful variety. Hopefully that gives you a
sense of what is meant.
>
> 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.
>
When an authcontext orchestrates multi-modules, then some of the
statefullness considerations I alluded to
above can become important; most notable of which is coordinating the
various CallerPrincipalCallback handlings
if each of the modules invokes the CBH with this CB. That problem is
left to the Context to solve, but I don't think
we ever found a particular satisfying solution for that.
> Here neither AuthConfigProvider.getServerAuthConfig
> and ServerAuthConfig#getAuthContext are passed in any context
> (MessageInfo).
>
> Any clarification here would be greatly appreciated.
>
Let me know if my explanation helps. If not, let's discuss further,
Ron
>
> Kind regards,
> Arjan Tijms
>
>
>