On Thu, Jun 20, 2013 at 5:27 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> Mark,
>
..
> Also please believe that all my technical thoughts are fair and
> related to technical issues only. My veto above is a technical veto.
I personally never doubted this based on your first mail, but that's
just because I know serf auth's framework so I recognized what you
were trying to see.
> I may agree that this problem should be fixed. But it should be fixed
> in the proper place and in the proper way.
>
..
> Did you read my email above? Let me explain again. Server advertises
> supported authentication schemes, for example Microsoft IIS:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: NTLM
> S: WWW-Authenticate: Negotiate
> S: WWW-Authenticate: Basic
> ]]]
>
> Then client decide which authentication scheme to use. Serf tries to
> Negotiate, then Basic. But with proposed patch serf will try
> Negotiate, then Basic and then NTLM again, which is wrong because NTLM
> authentication already handled inside Negotiate protocol. This is one
> of the reasons why I vetoed this patch.
From RFC 2617:
"The user agent MUST choose to use one of the challenges with the
strongest auth-scheme it understands and request credentials from the
user based upon that
challenge."
Serf now parses the WWW-Authenticate headers in order of appearance,
so we rely on the server being configured to add the most secure
scheme's header first, which from your example is clearly not
guaranteed.
We should make the order in which serf matches authentication schemes
explicit in both code and the documentation: negotiate, ntlm, digest,
basic.
> My point is that serf should use NTLM *only* if server doesn't
> advertise support Negotiate.
Hm, this statement should be more precise: per the ordering rules I've
noted above for your example, serf should try Negotiate first if it's
compiled in. If Negotiate fails to negotiate an authn scheme (kerb5,
ntlm or...), serf should try NTLM. If that fails fall back basic.
> mod_auth_sspi is too simple and supports only one auth scheme which is
> controlled by SSPIPackage configuration directive. For example with
> "SSPIPackage NTLM" it offer only NTLM:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: NTLM
> S: WWW-Authenticate: Basic
> ]]]
>
> Proper solution is to reconfigure mod_auth_sspi to use Negotiate auth
> scheme using "SSPIPackage Negotiate" directive. It this case
> mod_auth_sspi response will be:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: Negotiate
> S: WWW-Authenticate: Basic
> ]]]
>
> And serf will handle it. But neon doesn't work in this case :) Why
> you're not fixing neon?
This actually surprises me, neon has been supporting negotiate and
ntlm for years.
> You didn't understand properly my second point about duplicating
> authentication code that already there in auth/auth_kerb.c (it's
> actually should be auth_rfc4559.c). It's not aesthetic issue, because
> auth/auth_kerb.c handles a lot of different cases that could happen
> during rfc4559 style authentications. This code is platform
> independent and tested with various servers like mod_auth_kerb, Apache
> TomCat, IIS, VisualSVN Server and others. And NTLM implementation in
> serf should reuse this tested and complicated code in auth_kerb.c.
Agreed. We can't blame Bert for not recognising that most of the
auth_kerb_sspi .c code can be reused for NTLM, at the minimum the
filename doesn't match with the code it contains.
> I'm going to try to plug NTLM properly in the current serf auth
> architecture on the next week.
>
Great. Good luck. :)
For the record, I'm personally not planning to add NTLM to the unix
builds, so Ivan's work will be Windows only.
Lieven
> --
> Ivan Zhakov
>
> --
> You received this message because you are subscribed to the Google Groups "Serf Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to serf-dev+unsubscribe_at_googlegroups.com.
> To post to this group, send email to serf-dev_at_googlegroups.com.
> Visit this group at http://groups.google.com/group/serf-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Received on 2013-06-20 18:34:03 CEST