Re: KITTEN: IETF 75 - 76

[Michael B Allen <[e-mail]>]

On Tue, 01 Sep 2009 14:27:04 -0700
Love Hörnquist Åstrand <[e-mail]> wrote:

> 
> 1 sep 2009 kl. 10:31 skrev Nicolas Williams:
> 
> > Here's another based on background threads and a completion callback
> > instead of an event notification:
> >
> > 	major = gss_init_sec_context_async_cb(&minor,
> > 	    cred, &ctx, target, mech, req_flags,
> > 	    GSS_C_INDEFINITE, cb, &input_token, &output_token,
> > 	    &ret_flags, NULL, cb_func, &cb_data);
> 
> The callback should take all output variables, for example:
> 
> OM_uint32
> gss_acquire_cred_ex_f(gss_status_id_t /* status */,
> 		      const gss_name_t /* desired_name */,
> 		      OM_uint32 /* flags */,
> 		      OM_uint32 /* time_req */,
> 		      const gss_OID /*desired_mech */,
> 		      gss_cred_usage_t /* cred_usage */,
> 		      gss_auth_identity_t /* identity */,
> 		      void * /* ctx */,
> 		      void (* /* complete */)(void *, OM_uint32, gss_status_id_t,  
> gss_cred_id_t, gss_OID_set, OM_uint32));

Holy moses that's complicated. Do you really need callbacks? Why not just have a flag like GSS_C_NOWAIT that indicates the call should return immediately even if the overall operation has not completed yet? If the status indicates more processing is required (EAGAIN for C binding for example) it means that you need to call it again later. I use this technique in my own stuff and the implementation turns out to be surprisingly clean.

Also note that in an HTTP server if you cannot serialize the context while juggle concurrent authentications you may have to commit to using resources unnecessarily (such as processes on UNIX). That was my primary thought when I first posted to this thread. It's not clear to me that your model would help that scenario and that scenario is fairly important IMO. Would callbacks work with a stateless transport like HTTP?

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/