[Bug 27622] Pluggable SASL authentication

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27622

--- Comment #12 from Sjoerd Simons <sjoerd at luon.net> 2010-04-27 05:54:00 PDT ---
So i pondered a bit on how this should work, taking into account that we want
things to  just work when using old-style jabber auth and also make it possible
to plug something in which may just get your password asynchronously, but then
use wocky's built-in handlers to do the actual sasling.

So what we actually need is not a a pluggable handler per se, but it's a
pluggable handler selector/information gatherer :).. In the gabble case the
actual handler can be either be a remote process over dbus or one of the local
handlers if all the authentication handler gave us was the password to use.. So
my altered wocky design would be something like this:

 WockyConnector -> Wocky{Sasl,Jabber}Auth ->  WockyAuthRegistry -*->
WockySaslHandler

* WockyConnector is the current connector we all love and/or hate :)
* WockySaslAuth is also the same as currently, but with some functionality cut
out
* WockyJabberAuth does the same job as WockySaslAuth but for old-school
authentication, this functionality needs to be cut out of the Connector
* WockyAuthRegistry is a bad name for a new magical objec that does the
complicated work
* WockySaslHandler are the current sasl handlers as they are in master, they
won't need a change.

Now the task of WockyAuthRegistry is to find the right handler if possible and
proxy the challenges back and forward. When creating the WockyConnector object
you can optionally set your own Registry, otherwise the default will be used.
The register should be passed to Wocky{Sasl,Jabber}Auth at construct time. 

The async API of the Registry would be vaguely similar to what you changed the
WockySaslHandlers to atm. Although a tiny bit more streamlined (in my opinion
and feel free to change the names):

_start_authentication (<list of availble mechanisms, allow-plain-text,
is-secure-channel, user_name, maybe password, servername) -> (mechanism to use,
initial response if any) or error.

* Registery picks the authentication mechanism based on the given parameters in
whatever way, the builtin one would use the same algorithm to pick one and then
returns a value. While the
Gabble one would ask over dbus what the mechanism should be and gets an intial
response. 

_challenge (<challenge>) -> (maybe <response>) or error

* Nothing exiting the auth mechanism provides a challenge, the registry passes
it on to what ever the bit handling it is and gives back the result.

_success () -> maybe error

* Server claimed the authentication is finished, we let the handler check if it
agrees.

_failure () -> nothing

* Server claimed authentication has failed for whatever reason. The default
registry shouldn't need an implementation for this, but in the  gabble case we
probably want to relay this to the tp handler.

In case we're doing old-style jabber auth, we can define  "X-WOCKY-JABBER-AUTH"
or "X-WOCKY-JABBER-DIGEST". and pass that to the registry instead. Which means
we don't have to have seperate registry implementation for old and new style
auth (win!)

In case we want to support restarting we could add an extra async method
_restart? () -> bool, which if returning TRUE would start the whole process
from the beginning again. The default registry would always just return FALSE
here.

Now if you're extra cunning you make it such that if the Tp authentication
handler just gives you back a password and doesn't actually want to do sasl,
you just set the password propery on yourself/your baseclass and then from then
onwards proxy the _start/_challenge/_success onwards to the base class so you
use exactly the same code as if you were given a password (you might even
automagically want to do this if authorization is started with a password..)


Sorry for not getting into a design discussion with you earlier as you already
did a big chunk of work, but i think this design is both much simpler, more
elegant and address more of the use-cases we actually want to address..

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.