[Twisted-Python] Re: Questions about the Perspective Broker login mechanism

[Julien Peeters]

On Sun, 2007-08-19 at 16:37 -0400, David Bolen wrote:
> I'm not sure you need to change the login method signature, since it's
> just passing an arbitrary credentials object which can be as complex
> as you want.  But sure, you can make up your own checker interface to
> match your particular credential information.  Similar to how PB
> implements the IUsernameMD5Password checker to incorporate the MD5
> operation.
> 
> So, feel free to have at it.  There are probably a few ways you could
> take control, but I were doing it, I'd probably take my Portal
> subclass and make it directly implement IPBRoot (thus avoiding the
> registered adapter _PortalRoot).  Then use the existing classes
> (_PortalWrapper, _PortalAuthChallenger) as a model and/or subclass
> them, and build your own process from the IPBRoot rootObject() call.
> You'd be in complete control and can do anything you'd like.
> 
> If you haven't already, you might just start out with using the
> existing implementation since it'll be easy enough to replace out
> later and you might find that there are other aspects of the system
> that deserve attention before delving too deeply into the very initial
> authentication.
> 
> -- David

For the moment, except I make a mistake, only credentials which
implements IUsernamePassword are supported by the PBClientFactory.login
method. Then if, for instance, passwords are stored with a SHA hash
method, I can't use it as it is. 

Another case in which the implementation present for the moment does not
permit another credentials to be use: for instance, if the credentials
are based, on an other strategy than the username/password one, I think
it couldn't work too.

May be I misunderstood some important points. And at least a part of
what I've talk just before is possible.

What I would be able to do is to arbitrary choice any credentials, and
at the other side, that any checker which is able to check this
credentials is possible to use (I think it's already O.K. for the
checker part).

I thought at a solution, but I don't really know if it is a good one
(both from a design and security point of view). And in the case I made
a mistake in my comprehension, it would be useless.

May be it's possible to put a kind of "credential remote reference" at
the server side which serve as a proxy for the real credential. 
Form a security point of view it's all right because remote reference
does not transmit data but juste provide remote method calls.
And then, instead of give the _PortalAuthChallenger to the portal as the
credentials, that proxy would be given. The proxy have to implement the
same ICredentials interface to be compatible with the checker. And it
have also to implement a "zero-knowledge password proof" mechanism
(response/challenge) to communicate with the real credentials to
preserve security. 

This solution is based on the existing one. And may be would be more
flexible? Why not a starting point for an effective solution?

Julien.