client principal selection and UI

[Henry B. Hotz]

Following just my totally offhand opinions, and I may be wrong, in fact  
I've already changed my mind.  ;-)

On Jun 30, 2005, at 9:44 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 29 Jun 2005 16:31:19 -0400
> From: Sam Hartman <hartmans at MIT.EDU>
> To: krbdev at MIT.EDU
> Cc: daveo at apple.com
> Subject: client  principal selection and UI
> Message-ID: <tslekak9a7c.fsf at cz.mit.edu>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 2
>
>
>
>
> 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.

If you already have a service ticket for any client that matches the  
target then try it.  Of course to get to that point . . .

> 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.

Pop-up selection, based on existing tgt's (or recently acquired  
tgt's?), or fill-in.

> 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.

I like the idea of asking the server what it wants.  (DOS concern?)   
Some kind of fall-back to current d-r mapping behavior, then client  
realm (if different) (for referral).

That assumes that fallback/retry is feasible.  Reasonable assumption?

> 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?

Bind just the single server (but all services on it) permanently.   
Don't think you can presume the (DNS?) domain is the right boundary in  
all environments.  No UI if you have a binding, but need to make sure  
you re-present the initial dialog if you have any errors that might  
indicate a change/error in the binding.

However what I just said would probably result in a  
confusing/distracting dialog box after unrelated errors.  Not good.

I don't think I like any user interaction on this point.  I don't like  
spurious error messages.  I don't like making unjustifiable assumptions  
about the scope of a realm.

> 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.

See above imprecise statement.  They select from a menu.  If the  
selection is for an existing credential, done.  If selection is for a  
historical credential, filled-in dialog.  If selection is "new", then  
not-filled-in dialog.

I guess this matches what you said was probably undesirable, and a  
double-dialog interaction is an issue unless you can convince yourself  
that the second one will only rarely be needed.

I don't think the Mac UI guidelines would allow a pop-up menu to  
auto-close its dialog box after a selection.  I don't like the idea of  
presenting fill-in fields that are usually to be left blank.

If I suggest that the lower portion of the dialog should morph based on  
the pop-up selection at the top, is that reasonable to do  
cross-platform?

> ------------------------------
>
> Date: Wed, 29 Jun 2005 18:35:00 -0400
> From: Sam Hartman <hartmans at MIT.EDU>
> To: krbdev at MIT.EDU
> Cc: daveo at apple.com
> Subject: Re: client  principal selection and UI
> Message-ID: <tslk6kc7pwr.fsf at cz.mit.edu>
> In-Reply-To: <tslekak9a7c.fsf at cz.mit.edu> (Sam Hartman's message of  
> "Wed, 29
>  Jun 2005 16:31:19 -0400")
> References: <tslekak9a7c.fsf at cz.mit.edu>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 3
>
>
> There are a few things that I forgot to mention.  Frist, you will note
> that my proposal completely ignores the concept of a default
> principal.  The proposal is focused on an environment wher eyou have a
> lot of different services and realms and it is not clear you have a
> meaningful default principal.  I consider the question of deciding
> when default principals are useful and how they should work to be
> open.  I don't have good answers.

User preference selection.  I'll reserve what the default preference  
should be until I see what we come up with.

> The other big open issue is how you get default hinting.  For example
> you probably want some hinting so that you don't have to get prompted
> for the first time you talk to each service in your own local domain.

If there's a reasonable way to ask the server, that would seem to be  
ideal.

> I'll note that other models are possible that are a lot closer to what
> we have today.
>
> --Sam
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu