Hi,
On Mon, Apr 20, 2015 at 3:37 PM, Darran Lofthouse
<darran.lofthouse_at_redhat.com> wrote:
> It is about having multiple mechanisms all of which apply to the current
> requests (different mechanisms for different paths would be a different
> issue).
>
> As an example if you are going to support SPNEGO authentication and Digest
> authentication concurrently then both need to be able to generate their
> challenge so the client receives a request containing both challenges.
Right, so essentially stacking with 2 required modules? Or is that
still something slightly different?
I'd figure that 2 required modules would "just" send 2 separate challenges.
Kind regards,
Arjan Tijms
>
>
>> Standardizing module stacking has an existing JIRA issue:
>> https://java.net/jira/browse/JASPIC_SPEC-15
>>
>> I may be mistaken, but I vaguely remember that Anil Saldhana had some
>> opinions about this before JASPIC 1.0 went final.
>>
>> I did find SSO and/or "remember me" to be a little bit difficult to
>> implement using module stacking (especially when following the
>> PAM/JAAS conventions). A pipeline based on wrapping (like Servlet
>> Filters) felt a bit more natural vs a strict pipeline where each
>> module runs one before the next module runs. Maybe it's my lack of
>> experience there.
>>
>>
>>> When using a native protocol with something like SASL a lot of this can
>>> be
>>> achieved by listing all the supported authentication mechanisms to the
>>> client and allowing the client to use the one it wants to use.
>>
>>
>> While not exactly the same, this does seem to have some similarities
>> with letting a user in a web application choose the preferred
>> authentication method (e.g. a native form, OAuth via Facebook, etc).
>> There's an existing issue for this too, see
>> https://java.net/jira/browse/JASPIC_SPEC-16
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> Within HTTP
>>>
>>> this is not the case and you can actually end up with multiple mechanisms
>>> needing to run concurrently.
>>>
>>> Generally this is how the current AuthenticationMechanism API within
>>> Undertow was reached to support multiple mechanisms concurrently.
>>>
>>>
>>>> Should we use GF 4.X as reference server?
>>>>
>>>>
>>>> cheers,
>>>>
>>>> adam
>>>>
>>>> I broke my underarm, so my coding speed suffers a bit, but next week
>>>> should be back to normal.
>>>>
>>>
>