On 03/21/2011 03:03 PM, Henry B. Hotz wrote:
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.)
This should be OK but not the case when you use Kerberos password, RSA
token and bingo card at the same time.
It should be something like:
* Password with token
* PIV card with PIN
But IMO this is a more outside of the project functionality since the
client would have to out of band consult KDC (probably over LDAP or some
other mean) about what auth methods are allowed for the user on a given
host and then hint the server what combination the user actually provided.
There is a lot of the complexity in this scenario. I have been thinking
about it but this IMO next iteration of the project.
Let us run before we fly and we are not even crawling yet...
Thanks
Dmitri
> --
> 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
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/