new twisted.web._auth should support cred factories which don't send a www-challenge, and which send a final www-challenge

[philmayers]

Specifically, if you are hiding the Twisted Web server behind a proxy that does the authentication e.g. mod_auth_kerb in Apache, you might want the "credentials" to be:

X-Remote-User: foo

...and obviously the "XRemoteCredentialsFactory" would not send back a www-authenticate.

Adding a simple "if challenge" on line 51 of web/_auth/wrapper.py should do it.

More generally there might be auth schemes which want to use headers other than WWW-Authenticate (I can't think of one) so it might be better to generalise things further.

Also, I believe some auth methods (e.g. Kerberos with mutual auth) send a final WWW-Authenticate with the "200 OK" response.

I don't have time this evening to work up proof-of-concept code, but will take a look tomorrow

Given that the new auth code is not yet "released" it would be good to get this addresses before it is.

[exarkun]

Supporting Apache's mod_auth_kerb in twisted.web would be great. I'm not certain that HTTPAuthSessionWrapper is the place to do it. That class has a lot of code which is based on the idea of "HTTP auth", which is tied to www-authenticate and authorize headers. Something based on X-Remote-User probably belongs elsewhere. There's likely a lot of code in HTTPAuthSessionWrapper which can be factored up to a base class shared between it and a new X-Remote-User thing, though. And it may even make sense to make it possible to have either of these authentications wrapped around the same resource (that is, let the client make the decision, not the person deploying the software). On the other hand, with an authenticating proxy in front of your server, perhaps it isn't useful to allow that, as the deployer will always know which kind of authentication is possible.

Also, I understand the desire to have this in 8.2, but it's purely an enhancement to functionality which itself will be new in this release. I doubt that the release will wait for this to be finished, but if it is finished before the release, that's great too.

[philmayers]

Actually I came to much the same decision on the train. Multiple wrappers permits more flexibility.

See the attached code; I've tested it with mod_auth_kerb. It comes with (very limited) test suite.

As you correctly predicted there's lots of code which could be merged between the HTTPAuth wrapper and this one (and probably others).

Should I have a crack at merging the httpauth & remoteuser (i.e. my) code?

[philmayers]

FYI I've opened a ticket 3532 with a very basic (lacks tests currently) implementation of RFC4559 i.e. Negotiate auth in Twisted.web

[exarkun]

I can't see any reason this needs to be targeted at 9.0 (8.2+1).