client principal selection and UI

[Sam Hartman]

About a year ago we talked about selecting the realm (and thus client
principal) based on the target principal you are using.

We've gotten more interest in going forward with that work.  I'd like
to talk a bit more about one vision of a UI for that.  Alexis may have
another idea.  What is clear is that the UI is complicated and there
are a lot of API and usability concerns.  Please consider the
following discussion points.  We will need rounds of discussion
looking at how easy this is to implement and about how it departs from
what we do now.


I'd like to ignore several issues at this level.  First, I'd like to
ignore cases wher you have administrative or non-null-instance
tickets.  Second I'd like to ignore cases where you are using a client
principal different than the one you typically expect to use.  In
short I want to focus on default behavior.  Clearly we need to support
non-default behaviors as well but let's optimize for the default case.

So, you're going to a service that you've not gone to before and for
which you don't have good hinting information.  You will know the
hostname and service name; you may know the full target principal.

You pop up a authentication dialogue.  You default the client
principal to the default client principal.  The user can enter in a
client principal of their choosing.  You now know what client
principal to use for contacting this service.  You need to get tickets
for this client principal and you need to decide what realm to use.

Here are possibilities for what realm to use.  You can try the realm
of the client principal hoping for success or for a referral.  You can
try the realm that is indicated by your domain_realm mapping.  You can
ask the user.  Asking the user seems wrong: most users will have
enough trouble dealing with the client realm and will not be able to
deal with both a client and server realm separately.  Another option
is a certificate-like behavior where you ask the server what realm it
wants and pop up a dialogue if it doesn't meet some heuristics.


You then remember that this client principal is used with this server.
The question is how strong of a binding do you want?  Do you want to
bind to all servers in that domain?  Only this server?  How long term
of a binding do you want?  Does the binding mean you won't pop up a
dialogue ne next time if you have tickets for the bound client
principal, or will you pop up a dialogue with the fields filled in
already?

Another question.  How do you make the experience work well if the
user already has tickets for the client principal they select?  One
option is to always make them enter in a password and get new tickets
when you pop the dialogue.  Another option is to allow OK to be
pressed without entering a password if you already have tickets for
that principal.  Another option (probably undesirable) is to separate
the password entry from the principal entry.