Julien Peeters
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.
Ah, I see - sorry I missed that. Yup, so I agree you may want to override that portion of PBClientFactory (and perhaps the matching remote_login in PBServerFactory) in your own mechanism as well. It's possible the existing signature might still work even with a hashed password, since the password field from the supplied credentials are passed unchanged to the challenge response generation function, with nothing other than the client/server shared challenge/response implementation caring that it is clear text, but that does sort of "bend" the interface for IUsernamePassword so it's probably clearer to implement your own.
(...) 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.
Not sure this is a big win, since at some point in time you need to transfer over the actual credentials used for authentication anyway. So it's really a tradeoff between an established remote object method interface (to retrieve the credentials) or the type of credential object transmitted in general when sent as copyable data. Toss up, but you're free to try either approach.
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?
Why not indeed? If I were you and I had convinced myself the authentication approach was worth replacing in my application (per my last response) at this point I'd just go ahead and do some implementation to see how it goes. You can certainly achieve everything you're talking about by just overriding some of the existing default behavior. -- David