On Fri, Mar 18, 2011 at 03:36:53PM +0100, Linus Nordberg wrote:
Sumit Bose <sbose(a)redhat.com> wrote
Fri, 18 Mar 2011 14:23:40 +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.
That's of course unacceptable. Wouldn't postponing the request by
keeping a copy around and inject it in the event loop at a later stage
solve this?
I think in general yes, but I also think this would require even more
changes to existing code than what I've described above.
Regarding client retransmission, the KDC would have to recognise a
retransmitted message and resume the collection of preauth method
results. Is there a good mechanism for this already?
yes, this is handled quite nicely.
bye,
Sumit
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel