On 26/01/16 13:25, arjan tijms wrote:
> On Tue, Jan 26, 2016 at 2:04 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com <mailto:darran.lofthouse_at_redhat.com>> wrote:
>
> As a bare minimum I think we should verify the known existing HTTP
> authentication mechanisms can be covered.
>
>
> I agree, that's also why I started with the
> BasicAuthenticationMechanism. See
> https://github.com/arjantijms/mechanism-to-store-x/blob/master/jsr375/src/main/java/org/glassfish/jsr375/mechanisms/BasicAuthenticationMechanism.java
>
> It's not that we by all means needed that, but it functions as the most
> minimum of proofs that the API could at least do something.
>
> I intended to implement the other Servlet mechanisms (FORM, DIGEST,
> CLIENT) next. I found in the past btw that the simple FORM with the
> exact semantics as stipulated by the Servlet spec is often surprisingly
> difficult/laborious to implement
I also dislike implementing FORM authentication - however in terms of
verifying it's compatibility with an identity store API it is probably
not going to push the API any further than BASIC authentication as both
have a clear test username and password.
> With "HTTP authentication mechanisms" did you meant just these, or also
> HTTP SCRAM? To be honest, I have to read up on SCRAM to see how it
> exactly works.
HTTP Digest is a good mechanism to exercise an API, especially including
flows that include things like stale nonce and session support. It has
generally fallen out of favour due to it's use of MD5 - I haven't
checked the status recently but with regular efforts to get stronger
hashes supported I don't expect it to be long before it is viable again.
SCRAM should be considered later but I think Digest will do a good job
of verifying things first.
> I agree about the low hanging fruit - I will have a look and see if
> I can propose something to evolve it slightly.
>
>
> Okay, cool! The very latest version is still in my own branch, but I
> like to merge that soon into the security EG repo. I've largely based it
> on the discussions we had on this list earlier.
>
> Kind regards,
> Arjan Tijms
>