[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANONYMOUS SASL profile
Re: ANONYMOUS SASL profile
Wed, 14 Dec 2005 10:29:55 +0100
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
Francis Brosnan Blazquez <address@hidden> writes:
> First of all, congratulate for your effort on building GNU SASL.
Hi! Thanks for your interest.
Which GNU SASL version are you using? Below I assume you use the
> Well, I've found some problems while implementing the ANONYMOUS profile,
> as a first step on switch the proyect to GNU SASL.
> Once I've successfully initiated the client side to generate the base64
> anonymous token and send it to the server side, I've found that inside
> the execution requested for the GSASL_VALIDATE_ANONYMOUS callback, the
> GSASL_ANONYMOUS_TOKEN have a not properly formated string. According to
> the GNU SASL doc, it should contain the anonymous token.
You are right, it should.
> Explained in more detail:
> 1) Client side perform next calls:
> As as result the following base64 token is generated:
> 2) Server side receive previous token but before feeding gsasl_step64
> call with the previous base64 blob, next calls were issued:
> gsasl_step64 (*)
> (*) At this point, it is called the callback requiring to validate the
> anonymous SASL auth and, in our case, make the userid available for the
> context of the connection. So, a call to get the anonymous token is done
> from inside the callback with something like:
> anonymous_token = gsasl_property_get (ctx, GSASL_ANONYMOUS_TOKEN);
> g_print ("Anonymous auth requested: %s\n", anonymous_token);
What type is 'ctx'? It must be of the Gsasl_session type, not Gsasl.
> But as a result from previous call I get the following:
> "Anonymous auth requested: 'U\x89\xe5\x83\xec\x18\x89]\xf8\xe8R\xea\xff
> The validation callback is set using gsasl_callback_set.
That might happen if 'ctx' is the wrong type.
> Concrect questions could be:
> 1) How do I get current anonymous token received from the client side?
> I've tried to translate it supposing that it is a base64 encoded string
> but I didn't get the expected result.
You are using the right function, gsasl_property_get.
> 2) Do we need to create a new Gsasl context, using gsasl_init, for every
> connection we want to authenticate and then create the Gsasl session
> with gsasl_client_start/gsasl_server_start? Which is the intention on
> having the context and the session separeted and being created for every
> connection to authenticate?
The idea is the have one Gsasl context per application, and one
Gsasl_session for each client/server session in the application. This
is to make it as lightweight as possible.
Creating a Gsasl context for each session is slightly more expensive,
but compared to everything else I think it is very minor. The extra
time will be in gsasl_init, and setting any global callbacks.
There is no problem in creating multiple Gsasl contexts in an
application, if that would simplify your design.