Concerns about the Response_set interface

[Dmitri Pal]

On 07/17/2012 12:53 PM, Sam Hartman wrote:
> I missed a significant concern. I think the suggestions I made may
> already help manage this concern.
>
> Many of the credential acquisition applications support both MIT
> Kerberos and Heimdal.
> We need to minimize  future areas where credential acquisition gets in
> the way of portability.
>
> the current interface seems like it lends itself to
> implementation-specific data structures  that will make application
> portability challenging.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
OK, though I agree with the concerns here is the problem we need to
solve and we need to solve it for 1.11.

The server using FAST can now support a set of the authentication
methods including OTP via AuthHub project. This means that a set of
authentication methods can be requested by the server.

In future the software on the client would have to deal with a set of
the possible authentication methods supported by the server. It would
have to prompt user for selection or follow its (clients) policies to
choose a specific method on behalf of the user. It would also be able to
interact with hardware if needed (connected token or token inside hardware).

But this is a long shot and requires a lot of change to many related but
independent components (libkrb5, sssd, desktop etc.) The first step into
this direction is to allow the server to have a list of the
authentication mechanisms but for client to chose one based on its
policy and then prompt the user for that specific method i.e. control
which preau plugin will be used for the authentication and which token
if preauth plugin supports more than one like this is the case with AuthHub.

IMO the right place to do is in the kerberos library because right now
kerberos receives the set of the methods, re-orders them to put smart
card first (if requested by the server) and starts calling preauth
plugins in this sorted order which is viewed as a failover list rather
than the list of the real alternatives.
I think this is the first and major conceptual change we should embrace
here. How to implement it without changing the exiting applications?

My thought was that we need a callback that the library would invoke
that would allow the application to see what authentication methods are
available. It then would be able to either prompt the user in future or
select the right method based on the policies. After that the library
will continue calling preauth plugins but will call only the preauth
plugin that was selected via the first callback. The rest would be
ignored. I will call this callback a "selection" callback.
IFAIU the main problem with this approach is that there is no interface
right now to pass this callback to the library. A new initialization
function would have to be added. Is it a big problem?

It would also be nice for the "selection" callback to get a list of the
authentication methods in some kind of a unified form. An authentication
method can be represented as a structure close to the token info (if not
token info itself). That detail really does not matter ATM but needs to
be figured out.

Everything would have been perfect with this solution if the preauth
methods had one to one relationship to the actual authentication
methods. If that were true it would have been enough to determine one
preauth method in the "selection" callback and call it. But the problem
is that the OTP spec allows multiple OTP tokens. This means that the
"selection" plugin needs to pass extra data (which OTP method was
selected) to the preauth plugins - this would be an ABI breakage.

To work around this we say that now all the preauth plugins have to
implement yet another callback to get this "selection" information. If
this is the case than the problem can be solved by just having that
callback and no "selection" callback (at least for now as we do not need
to present the whole list to the user to pick).
So every preauth method would have to call and ask "am I selected?" and
only if it is selected actually prompt the user using the standard
prompting interface.

I think the confusion is that we need to separate two problems here:
which method to prompt for and actually prompt user or hardware (in
future) for the input.

While prompting interface is most likely Ok as is for now the
"selection" functionality is the high priority.

I do not know the details to say whether what Nathaniel proposes solves
the problem but I hope I explain what we are trying to accomplish.

And also I do not want to overengineer things, let us have something
simple that move us into the right direction and would allow use of the
authhub in the first place (without the "selection" capability it can't
be used).
This is why the idea was to create an interface that would allow to move
forward and see by try and error what actually needs to be done later. I
am open to treating the new interface experimental and evolve it over
time breaking and fixing authHub but if we try to design the whole thing
now we will get in the weeds of complexity and would never be able to
finish this for 1.11 which is a hard requirement for us.  


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/