Topics

Public Review Draft - Multiple Authentication Mechanisms


Darran Lofthouse
 

One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together.

A common scenario I see requested is CLIENT_CERT, with SPNEGO, with FORM.

CLIENT_CERT is possible to silently handle but the other two both require sending to the client simultaneously.

Regards,
Darran Lofthouse.


Arjan Tijms
 

Hi Darren,

There's A LOT of things that unfortunately didn't get coverage. For the longest time it was basically just me doing some JSR 375 stuff during my daily commute.

I remember your multiple authentication mechanism proposal with the 2 phase process request and write response. It sounded good like I mentioned back then, but nobody came forward to actually put in some work for it, and I very unfortunately didn't had the time for it.

Likewise, if Rudy hadn't put in all the initial work for the multiple identity store proposal, I very unlikely would have been able to code that up on my own. Still, I love to see this being addressed for a 1.1 or 2.0 of JSR 375.

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 5:15 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together.

A common scenario I see requested is CLIENT_CERT, with SPNEGO, with FORM.

CLIENT_CERT is possible to silently handle but the other two both require sending to the client simultaneously.

Regards,
Darran Lofthouse.



Darran Lofthouse
 

I think my bigger concern on that one is it is very hard to retrospectively fit it in once mechanisms have been implemented, mechanisms need to be coded to separate the challenge phase from the response handling phase from the outset.


On Thu, 6 Jul 2017 at 19:39 Arjan Tijms <arjan.tijms@...> wrote:
Hi Darren,

There's A LOT of things that unfortunately didn't get coverage. For the longest time it was basically just me doing some JSR 375 stuff during my daily commute.

I remember your multiple authentication mechanism proposal with the 2 phase process request and write response. It sounded good like I mentioned back then, but nobody came forward to actually put in some work for it, and I very unfortunately didn't had the time for it.

Likewise, if Rudy hadn't put in all the initial work for the multiple identity store proposal, I very unlikely would have been able to code that up on my own. Still, I love to see this being addressed for a 1.1 or 2.0 of JSR 375.

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 5:15 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together.

A common scenario I see requested is CLIENT_CERT, with SPNEGO, with FORM.

CLIENT_CERT is possible to silently handle but the other two both require sending to the client simultaneously.

Regards,
Darran Lofthouse.



Arjan Tijms
 

True, but something like an HttpMultiAuthenticationMechanism can be build on top of the existing HttpAuthenticationMechanism if you consider its validateRequest method just as the initial point in time where the container gives us access to the request and response. We indeed should not try to make the existing HttpAuthenticationMechanism multi capable.

Existing implementations of HttpAuthenticationMechanism would also not be used together with the HttpMultiAuthenticationMechanism, following the rule that there's only one HttpAuthenticationMechanism. But that one HttpAuthenticationMechanism could orchestrate the mechanisms as per your original 2 phase proposal.

It's a petty we couldn't put this in 1.0 as mentioned, but I'm afraid it is what it is (if it's any consolation, I spend a significant amount of time prototyping the custom authorization rules, but these also did not make it in :()

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 11:40 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
I think my bigger concern on that one is it is very hard to retrospectively fit it in once mechanisms have been implemented, mechanisms need to be coded to separate the challenge phase from the response handling phase from the outset.


On Thu, 6 Jul 2017 at 19:39 Arjan Tijms <arjan.tijms@...> wrote:
Hi Darren,

There's A LOT of things that unfortunately didn't get coverage. For the longest time it was basically just me doing some JSR 375 stuff during my daily commute.

I remember your multiple authentication mechanism proposal with the 2 phase process request and write response. It sounded good like I mentioned back then, but nobody came forward to actually put in some work for it, and I very unfortunately didn't had the time for it.

Likewise, if Rudy hadn't put in all the initial work for the multiple identity store proposal, I very unlikely would have been able to code that up on my own. Still, I love to see this being addressed for a 1.1 or 2.0 of JSR 375.

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 5:15 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together.

A common scenario I see requested is CLIENT_CERT, with SPNEGO, with FORM.

CLIENT_CERT is possible to silently handle but the other two both require sending to the client simultaneously.

Regards,
Darran Lofthouse.




Darran Lofthouse
 

Yeah I think for now single is fine - TBH this is really focussed on the authentication for a specific application and I would expect the primary reason this is used initially is where the container provided authentication is not sufficient.

HttpMultiAuthenitcationMechanism could probably as you say be added at a later point, if two new methods were added to response handling and challenging this new interface could likely extend HttpAuthenticationMechanism with a default implementation of the validateRequest method calling both of the new methods at the appropriate time - this way a new multi capable mechanism could still be used in place of an original mechanism.

Regards,
Darran Lofthouse.


On Fri, 7 Jul 2017 at 00:34 Arjan Tijms <arjan.tijms@...> wrote:
True, but something like an HttpMultiAuthenticationMechanism can be build on top of the existing HttpAuthenticationMechanism if you consider its validateRequest method just as the initial point in time where the container gives us access to the request and response. We indeed should not try to make the existing HttpAuthenticationMechanism multi capable.

Existing implementations of HttpAuthenticationMechanism would also not be used together with the HttpMultiAuthenticationMechanism, following the rule that there's only one HttpAuthenticationMechanism. But that one HttpAuthenticationMechanism could orchestrate the mechanisms as per your original 2 phase proposal.

It's a petty we couldn't put this in 1.0 as mentioned, but I'm afraid it is what it is (if it's any consolation, I spend a significant amount of time prototyping the custom authorization rules, but these also did not make it in :()

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 11:40 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
I think my bigger concern on that one is it is very hard to retrospectively fit it in once mechanisms have been implemented, mechanisms need to be coded to separate the challenge phase from the response handling phase from the outset.


On Thu, 6 Jul 2017 at 19:39 Arjan Tijms <arjan.tijms@...> wrote:
Hi Darren,

There's A LOT of things that unfortunately didn't get coverage. For the longest time it was basically just me doing some JSR 375 stuff during my daily commute.

I remember your multiple authentication mechanism proposal with the 2 phase process request and write response. It sounded good like I mentioned back then, but nobody came forward to actually put in some work for it, and I very unfortunately didn't had the time for it.

Likewise, if Rudy hadn't put in all the initial work for the multiple identity store proposal, I very unlikely would have been able to code that up on my own. Still, I love to see this being addressed for a 1.1 or 2.0 of JSR 375.

Kind regards,
Arjan Tijms





On Thu, Jul 6, 2017 at 5:15 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together.

A common scenario I see requested is CLIENT_CERT, with SPNEGO, with FORM.

CLIENT_CERT is possible to silently handle but the other two both require sending to the client simultaneously.

Regards,
Darran Lofthouse.