jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] Re: Sec Spec Spike

From: Darran Lofthouse <darran.lofthouse_at_redhat.com>
Date: Mon, 20 Apr 2015 14:37:28 +0100

On 20/04/15 14:30, arjan tijms wrote:
> Hi,
>
> On Mon, Apr 20, 2015 at 3:13 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com> wrote:
>> On 15/04/15 08:31, Adam Bien wrote:
>> #2 There is a lot of demand for multiple authentication mechanisms to be
>> supported concurrently, a common combination being SPNEGO, some form of
>> username / password (Form, Basic, Digest etc...), Client Cert and then maybe
>> even combine this some form of SSO.
>
> Do you refer here mostly to different mechanisms being tried in turn
> (module stacking) or to having multiple mechanisms being configured
> for different paths within the same application?

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.

> 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.
>>>
>>