On Fri, Mar 18, 2011 at 02:09:40PM +0100, Linus Nordberg wrote:
Sumit Bose <sbose(a)redhat.com> wrote
Fri, 18 Mar 2011 12:56:35 +0100:
| Also having an event loop would be only the first step. The internal
| preauthentication API needs to be aware of asynchronous
| preauthentication methods. My current idea around this is that
| asynchronous methods return a flag like PA_ASYNC and are skipped by the
| current preauthentication code until all other pa-methods are handled.
| If there are no PA_ASYNC methods the results (edata, encrypted keys,
| errors) are returned to the client. Otherwise all PA_ASYNC methods are
| called (with a new, to be defined async preauthentication API), their
| results are collected and then the results are send to the client. This
| approach would require only a minimal change to existing code, but as
| always, the devil is in the details :-).
If collecting all the async methods is anticipated to be taking too
long(*) for the client, how do we trigger a new round of collecting
results? Can we return some (newly invented error) resembling EAGAIN to
the client and then inject the original as-req into the event loop again
once the client gets back to the KDC?
No, the client just has to wait until it gets some response from the
server and iirc the MIT client libraries will resend the as-req once
every second until an answer or some timeout is received. The problem is
on the server side. Currently the MIT KDC can only process one request
at a time and if an external authentication step needs a couple of
seconds the whole server is blocked for this time.
bye,
Sumit
Does this make sense at all? I might have misunderstood the issue
completely.
(*) What is the number for "too long for a client"? Like one second?
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel