On Sat, 19 Nov 2005 23:00:31 +0000, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
David Reid wrote:
But in Basic and Digest auth you don't have the username until you get the response to your challenge. So this is where IAuthorizer comes in it handles all the steps prior to having something that you can use to build a credentials.
I'm no cred expert, and I dislike it conceptually, but as far as I can tell it's got all the facilities it needs. HTTP is slightly more complex so I'll start with a SASL-ised imap-like example, to see if I've got the right idea:
[snip - cool example protocol with cred integration]
HTTP is a bit of a pain because of the "connectionless" basis. The RFCs for the hacky mechanisms like "Negotiate" (the MS-ism for kerberos over HTTP) and such show that. Digest would want some kind of stateless version - you're effectively authenticating requests as opposed to the connection, but the basic principle is the same. I'm sure you know all this.
So am I missing something? It looks like cred needs no extending?
Nope. You're dead on. Cred can do everything necessary to handle Digest auth as-is. Digest auth isn't even the most complex scheme it supports. I wrote the attached quick example of authentication that involves repeated challenges and per-user private authentication-required state. It is mainly the same as your example, with the addition of support for a kind of credential that requires cooperation from both the authentication database and the protocol. Jean-Paul