Credential cache searching, ccapi and file caches

[Sam Hartman]

Currently, you can only have one client principal active at a time.
If you try to authenticate to a service then the library will try and
get tickets for that client principal and for the requested service
principal  using cross-realm authentication as necessary.  There are a
number of cases where people may have principals in multiple realms
and would like better automatic behavior.  

The desired user experience is that if you attempt to authenticate to
a service and have a principal in the realm of that service for which
you have tickets then that client principal will be used.  If you have
no tickets in the realm of the service and if cross-realm is
unavailable, then you will be asked to obtain tickets in that realm.


There are two issues I'm ignoring in this message.  We're quite well
aware of them and do acknowledge they need to be solved.  The first is
how to manage API changes to allow you to call gss_init_sec_context
and/or krb5_mk_req_ext  without a client principal already specified.
The second is how this all interacts with cross-realm authentication.

What I do want to discuss is how this interacts with CCAPI and
credential caches and how these tickets get stored.  I believe Jeffrey
Altman and Alexis have already discussed these issues, but there
discussion is not archived.  Hopefully I'll come to similar
conclusions; if not they can set me on the right path.

I'd like to start with a brief summary of how CCAPI works now to
confirm my understanding and to bring people not familiar with CCAPI
up to speed.  A CCAPI cache collection is a set of caches that live in
one cache server process.  Caches contain a set of credentials for
both v4 and v5  and associated with the credentials is a principal.
That is, all tickets in a single ccapi cache are expected to  have the
same client principal.  For the most part there is at most one cache
with a particular client principal at any given time.  

There is a system default cache  which is the default cache used by
the ccapi.  I'll pretend for the rest of this message that there's
also a system default principal; think of it as the principal of the
system default cache.

File caches work differently.  I'm only going to think about v5 file
caches.  A v5 file cache contains a principal and a set of
credentials.  There is no requirement that the client principal be the
same for credentials in the cache nor that it be related to the
default principal of the cache.

                             Requirements

KFM--particularly KLL and Kerberos.app would require significant
revision if we change how CCAPI works.  They expect to be able to
enumerate through all the caches , to have one cache per principal,
and for a given cache to enumerate all the credentials in a cache.

The Kerberos library also  would require significant revision if we
change its idea of how caches work.  The krb5 library assumes that
most operations have a single krb5 ccache object that refers to all
the tickets that might be needed by that operation.  


                               Proposal

First,  I think we should mandate that at most one ccapi cache refer
to a given principal at a given time.  A lot of the code sort of
assumes this is true and I think it will make things easier to make
this an invariant.

I think that we should change the interface between the krb5 library
and the ccapi.  The krb5 ccache type corresponding to a ccapi cache
should correspond to a cache collection rather than a single cache.
If you ask this cache for its default principal then it would
give you the system default principal.  If you  enumerate tickets,
then you would get all the tickets in all the ccapi caches.  Note that
I'm not talking about changing ccapi, just how the krb5 library views ccapi.

File based caches already basically map onto ccapi cache collections.
I think that in order to allow Kerberos.app to view file based caches,
you would want a ccache operation that enumerated all the principals
in use in a given cache.  You already have an operation to get all the
credentials with a given client principal.

What do people think?