Re: NTLM authentication : some questions

Robert Collins wrote:

> * Is Andy Doran still around/active - I'm happy to work with him on this, or
> is it currently unmaintained?

I don't know. All I know is that I haven't heard anything from him in a
long time.

> * With regards to your proposed auth_class directive, I suspect your
> architecture would fall over with systems such as Metaframe.

I don't. A single metaframe server can't be member of different domain
structures with discticts user databases, or else users won't be able to
log on to it in a non-ambigous manner.

> I think that the structure discussed should allow the same flexability,
> particularly if we were to look at allowing more than one instance of a
> given auth_type helper program - as long as we put a sanity check in the
> acl parsing code to prevent collisions, the same functionality should just
> drop right out.

You are forgetting one important thing, and that is caching of user
validity. You don't want to have the user revalidated on each and every
request. The auth_class expands the internal user identity with a
internal tag to be able to distinguish two users named "robert"
depending on where in the network they are.

> * Has anyone got/seen/able to _easily_ get, what a NTLM browser passes as
> X-Proxy-Auth on subsequent connections? This is related to the two DENIED
> messages.

log_mime_hdrs should log them. Not sure if it does. The only NTLM
authentication traces I have seen is from traffic dumps where IE is
logging in to a MS IIS web server.

> * How does this sound as a fairly safe way to avoid logging the two DENIED
> messages on every connection:
>
> For the first request, log the DENIED. Present all applicable auth
> types. If _any_ auth type requires handshaking, set a AUTH_IN_PROGRESS FLAG.
> on the next part of the handshake, if AUTH_IN_PROGESS is set, AND the
> browser returned a matching handshaking auth-type, AND the auth code returns
> AUTH_IN_PROGRESS again DO NOT log anything. Otherwise log a DENIED and reset
> any AUTH_IN_PROGRESS flag. (next request will start with a clean slate).
> and so on for n AUTH_IN_PROGRESS steps, where n is the longest handshake
> we know of.
> When the auth_code returns a valid username log the request and if
> possible keep as a state item whatever we expect to see from that same
> authenticated client again on their next new tcp connection.
> If we see such a token, it's the same user, log and process the request
> as normal. (ie still check that that user is allowed, but don't start a new
> handshake process).

Sounds safe, but for sanity I guess you should also verify that the URL
is the same on the hidden request as the logged request. Another option
is to log the denied requests where AUTH_IN_PROGRESS is set with another
log tag..

> Also we looking to extend the auth helper's responses and expected inputs to
> allow handshaking or non-handshaking as appropriate for each auth type. At
> the same time we will add multiple-auth-helpers so that
> kerberos/digest/basic/ntlm code does not have to be rolled into one. Is
> anyone working on that sort of thing at the moment or is it a clean slate?

Noone besides you is working on anything in the direction of
authentication as I know of.

> Critical to good performance on this will be the ability to write the
> request to the authenticator, and read the response as a call-back, pausing
> the acl check - does anyone predict problems with this? I think the
> redirector does something similar doesn't it?

No problem. It is how it works.

Another very important issue is to be able to cache the user validity.
For NTLM I guess this means replaying the same challenge for a period of
time.

> And finally to anyone who has looked at the changed request flow in the NLTM
> branch vs the head request flow - does anyone have any
> preference/input/comments/suggestions? I suspect that the approach we've got
> may fit better with the existing flow.....

Can you specify in more detail what you are referring to? I think it is
my change for allowing a sane processing of request entities, but maybe
something else? Sane processing of request entities is required, or you
won't be able to do any challenge/response authentication on such
request.

> Note: for the moment I'm ignoring NLTM WWW authentication thru the proxy.
> That should not affect the Authentication code.

No problem. They are completely unrelated, other than that they have the
same requirement on connection persistence between the browser and the
authenticating server, no matter how many HTTP hops there is between the
two.

/Henrik
Received on Mon Jul 31 2000 - 17:14:31 MDT