[Twisted-Python] mind, twisted.cred and HTTPAuthSessionWrapper

[Jean-Paul Calderone]

On Thu, 19 Feb 2009 20:22:30 +0100, Esteve Fernandez <esteve at sindominio.net> wrote:
>On Thursday 19 February 2009 19:46:59 Jean-Paul Calderone wrote:
>> >But, in our case, requestAvatar can only return something based on what
>> > the checker returns. I mean, requestAvatar receives an avatarId (as a
>> > result of Checker#requestAvatarId), a mind and a bunch of interfaces, but
>> > the realm doesn't have any other information.
>> >
>> >What our checker does to authenticate an user, is to call a method on a
>> > remote service and get back an object (a token) that represents the state
>> > of a conversation between a client and that remote service. Then, the
>> > client may issue more remote calls using the previously received token.
>> >
>> >We're using Twisted.web only as a front end to a remote service, and we'd
>> > like to make it as decoupled as possible, as there will be other
>> > frontends.
>>
>> What if you use the token as the avatarId?
>
>But the general contract for requestAvatarId is to return a string identifying
>the user. From ICredentialsChecker#requestAvatarId documentation:
>
>"Returns - a Deferred which will fire a string which identifies an avatar, an
>empty tuple to specify an authenticated anonymous user (provided as
>checkers.ANONYMOUS) or fire a Failure(UnauthorizedLogin). Alternatively,
>return the result itself."
>
>If so, our problem is that the token is an object that contains more
>information (a timestamp, a cryptographic signature, etc.), so serializing
>and deserializing it everytime we need that information is a bit cumbersome.
>The remote service checks that token everytime it receives a call, and
>responds with an appropiate response.

The convention is for avatarId to be a string, but as the anonymous case
indicates, that's not strictly required. :)  The real requirement is that
the realm be able to interpret the avatarId.  The way this generally works
is by making it a username string, but you're in charge of the realm, so it
can be whatever you like.  Of course, this makes it harder to re-use either
your checker or your realm with different components, but sometimes that's
okay.  It might be nice if this were explained in some document somewhere
but I don't think the current cred document should cover it, since going
into complex and subtle points like this tends to make it harder to get
the basic idea.  An advanced cred howto of some sort might be merited.

>> >I tried to mimic PB's behaviour, in the sense that (as the cred
>> > documentation puts out):
>> >
>> >"it is an object which serves an important role - any notifications which
>> > are to be relayed to an authenticated client are passed through a 'mind'.
>> > In addition, it allows passing more information to the realm during login
>> > in addition to the avatar ID."
>>
>> This is technically true but as far as I know no one has ever actually used
>> it that way.  I'm trying to think of an authentication scheme which would
>> benefit from it (let alone require it), but I'm drawing a blank.  PB just
>> has enough expressive power already to really need this.
>
>In that case, (although we might not actually need a mind in the end), would
>PB have the same problem with HTTPAuthSessionWrapper? The mind argument is
>always None (in HTTPAuthSessionWrapper#_login):

I'm not quite sure what you mean here - how should I equate PB and
HTTPAuthSessionWrapper?

>    def _login(self, credentials):
>        d = self._portal.login(credentials, None, IResource)
>        d.addCallbacks(self._loginSucceeded, self._loginFailed)
>        return d
>
>So, I think HTTPAuthSessionWrapper should have a method (e.g.
>createMind(self)), which would return None by default and that could be
>overridden by subclasses if they need to return something else. I'll gladly
>file an issue, provide a patch and a test case, if you think it's a valid
>issue.

It probably *is* a good idea to allow the mind to be created somehow.  It
was only omitted because no obvious use-cases presented themselves at the
time.  I'm still not really convinced that this use case is a good one
though, so I'm not sure I'd be in favor of adding the hook now in order
to support this. ;)

In general, the mind feature of cred is underutilized, underdocumented,
and poorly understood.  Fixing these problems is great, but it may also
be the case that the mind is such an obscure use-case that most people
really just don't care about it.

Jean-Paul