[Twisted-web] Sessions and Authentication for Web2
p.mayers at imperial.ac.uk
Sun Nov 27 14:31:41 MST 2005
David Reid wrote:
>>> c) Exarkun expressed a strong (ok, mandatory) preference for the
>>> use of tw.cred in any Authentication solution. However, it was
>>> noted that tw.cred does not allow for challenge-response
>>> authentication mechanisms (which all of mine are). Specific
>>> examples were noted: twisted.protocols.sip, SASL, OTP
>> Hmm. How did you get this idea? Cred's design was specifically to
>> facilitate challenge-response authentication. That's why login()
>> takes credentials and returns a Deferred. The assumption is that the
>> credentials object will encapsulate whatever facets of the user's
>> connection are required to do the negotiation process.
> While it might be a valid assumption, there is no common public
> interface provided to facilitate it. Perhaps because no one knows what
> that should look like, perhaps because no one felt it was necessary.
> But I do believe that something like twisted.protocols.sip.IAuthorizer,
> that allows for an arbitrary number of round trips should be in cred,
> either the ICredentials interface should be extended (probably through a
> subclass) or a new interface should be created. I'm toying with some
> ideas of how to best do this, but I don't really "get" cred so if you
> have any requirements other than arbitrary number of round trips, let me
> know so i can take those into account now rather than later.
I've been thinking more about this and I can indeed now see a slight
impedance mismatch that I haven't yet thought my way around. I got here
from thinking about implementing Negotiate support using PyGSS.
Exarkun and I posted examples of how one might do arbitrary
challenge-response by making the creds a proxy object to the protocol
instance, and I waved my hands saying "HTTP is a bit more hard because
of the statelessness / request-based nature of the protocol".
The best I've come up with that in theory supports >1 auth mechanism
To "match" HTTP to t.cred, it seems the "credentials" *are* the HTTP
request object (which in fact is true, given how the HTTP spec is worded
I think?). There's then a checker that can "check" HTTP requests against
sub-mechanisms, and if none work then one or all of them can challenge
This seems somewhat hackish as the "checker" then has to know about
"name: value" rfc2822-style protocol PDUs, as opposed to just the
elements of the auth algorithm. It might be more palatable if you could
somehow "chain" checkers - e.g. return an IDigestCreds from
requestAvatarId, or maybe have some kind of 2-pass thing?
[FreeRadius has an interesting thing in it's "authorize" config section
where you first pass the request through the "authorize" section to
determine how to authenticate it (and optionally return there and then
with challenges etc.) then pass it through just one module as defined by
the auth-type. This will mean nothing to you unless you've seen it, but
that's what I mean by 2-pass]
On the other hand, this is a very flexible system as it permits you to
allow based on other portions of the request such as arbitrary headers,
SSL cert for the TCP connection, and so on.
(Note to all: a load of the code is ripped from the t.p.sip code, so
appropriate credit where it's due. The stateless nonce thing might be
worth ripping though)
 t.w.http does not appear to allow you to set headers >1 time e.g.
WWW-Authenticate: basic realm="server.domain.com"
WWW-Authenticate: digest realm="...",foo="bar",...
More information about the Twisted-web