[Twisted-web] Sessions and Authentication for Web2

Phil Mayers 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[1] 
is here:


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 
the request.

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)

Comments welcome.

[1] 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 mailing list