On Mar 21, 2011, at 7:18 AM, Dmitri Pal wrote:
On 03/18/2011 09:10 AM, 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?
>
> 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
We need to have experts from MIT on the list to continue this discussion.
I think current client timeout is 1 sec.
That's standard. Don't know that anything changes with FAST, but it's at
least possible.
[. . .]
The plan is to support one external authentication method per auth
request and allow multiple external auth methods to coexist nicely on
one KDC for different subsets of the users.
Makes sense. The framework allows methods to require other methods to succeed before they
operate, but I have a hard time visualizing a likely real-world case that requires that.
Having more then one external method for the same user combined
together
is too complex and is not a use case that needs to be solved right away.
OK, but I think it's likely that many users will have all the methods as possibility.
I have a password, RSA token, and a PIV card for example. (And two of those already work
with my deployed Kerberos service.)
--
Thank you,
Dmitri Pal
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz(a)jpl.nasa.gov, or hbhotz(a)oxy.edu