[Twisted-Python] twisted and kerberos
p.mayers at imperial.ac.uk
Fri Sep 16 07:24:31 EDT 2011
On 16/09/11 02:16, Benjamin Rutt wrote:
> Hello twisted experts,
> We are trying to add kerberos authentication to our existing twisted
> server. We haven't yet found a twisted specific library that can do
> this; any pointers?
Over which protocol?
Do you only want authentication, or integrity/confidentiality as well?
> What we have found is python-krbV
I've used PyKerberos before to implement HTTP Negotiate auth for Twisted
Web, but PyKerberos doesn't give you any integrity, and only client-side
The state of python Kerberos/GSSAPI libraries is a bit poor, so I wrote
my own in Pyrex!
> (https://fedorahosted.org/python-krbV/), but we end up using it along
> with code like this to take over the socket ourselves from twisted, when
> the client connects:
> and then we use the self.transport.socket directly in blocking mode in
> another thread (so it won't block the reactor). In particular, we use
> code like this to start the authentication process:
> ac = krbV.default_context().sendauth(self.transport.socket, ...)
> …once the client has authenticated, we use:
> to let twisted take over the socket again for the rest of the conversation.
> So in the event there are no ready-to-go twisted libraries for kerberos,
> is the above approach totally insane?
So you're server-side?
I would advise using the GSSAPI stuff in PyKerberos; you drive the
"authGSSServer*" functions in a loop, it gives you back the tokens and
lets you handle the network transport yourself, so is easier to
implement with Twisted.
Beware of course that the underlying GSS mechanism might block at any
time; although in my experience this doesn't happen server-side, when
using the Kerberos mech.
This will only be an option of course if you have control of the client
and can switch to using GSSAPI there too.
Alternatively, you could modify your existing approach so that the
entire Kerberos stuff ran in a deferToThread call, talking over a pipe
or loopback TCP socket back to the main reactor, then use a dummy
protocol to move the data back and forth to the "real" protocol. There
may be easy/clean ways to do this using various Twisted utilities like
twisted.protocols.policies.ProtocolWrapper, but I can't think of a
design right now.
More information about the Twisted-Python