client principal selection and UI

[Jeffrey Altman]

I know that Sam is aware of this but I figure I should make it clear for
everyone else on the list.   Whatever path we choose to take is going to
require changes to both the raw krb5 api and the gss api.  At the moment
we have some hooks in the gss_acquire_cred() that allow an "Obtain
Credentials" dialog to be displayed to the user when there are no TGTs
available.

Unfortunately, there is simply not enough information available within
gss_acquire_cred() to determine which principal to use.   The function
does not have access to the service name the application eventually
wants to communicate with.   Without that information, we might as well
choose a random principal.

Assuming that we did have access to the service name, we would be able
to build a database of user principal names and passwords that had
previously used to access the service in the past.   I believe the model
we desire is very similar to the one currently implemented in browsers.
When you go to a web page that requires authentication, you are asked to
provide the necessary credential.  In the case of username and password,
the browser will remember the user name and optionally the password.
The next time you go to the page the browser will use the information
you provided the previous time to pre-populate the enter credential
information dialog.   If you used multiple names to access the page,
you are given a choice of which you want to use and the ability to
enter a new name.

With regard to the question of "should a user be required to enter
the password again if an existing TGT for the specified principal
already exists?"   I believe the answer is that we should not.  In the
OpenAFS for Windows Credential Manager I added the ability to re-use
an existing principal with a TGT for obtaining service tickets.   In
my UI, the password field is disabled if the user already has a valid
TGT.  I think this is the appropriate model.

I should point out that there has been much discussion regarding access
to HIPPA protected services.   Under the HIPPA rules, when a user
accesses a HIPPA protected service, the user MUST re-authenticate to the
login server for each and every access.  According to these rules, a
user would always have to obtain an Initial Service Ticket for the
service when the service is accessed.  Using a TGT to obtain the service
ticket is not permitted.  The only way that a client would know this is
by querying the KDC or some other remote database.

The downside of permanently caching all of this data is that we must
provide UIs for the user to manage it.

I can ramble some more on this topic in the future.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050701/359cbec7/attachment.bin