What do you want from your credentials cache? (was Credential cache searching, ccapi and file caches)

[Alexandra Ellwood]

Before I answer Sam's comments, I'd like to take a step back and ask 
the user and developer community some questions.  I think that by 
presenting a mostly finished design, we ended up asking people to 
interpret the implications of the design (something people probably 
don't have time for) rather than just asking "what do you want this 
feature to do?"

I've included a preamble for those of you who are just tuning in.  If 
you were following the previous messages just scroll down to the 
questions.


The Problem:

We've gotten a request to improve our support of the case where the 
user has multiple TGTs for client principals in different realms which 
do not share keys.  The requester has a valid reason for not being able 
to share keys between the realms, so we are interested in helping them.

Currently the user has to switch the default ccache (either with 
KRB5CCNAME or the CCAPI default ccache) to the one that works and then 
try to get the service ticket.  What we would like is for the library 
to automatically find the appropriate TGT and get the service ticket.


Why we have to change the way caches work:

Currently on Unix platforms, users store each set of tickets in a 
separate file-based cache.  Each cache has a default client principal, 
a name (the path to the file) and a list of tickets.  The name of the 
cache currently in use is stored in the environment variable 
KRB5CCNAME.  Unfortunately, there is no list of all the user's 
file-based caches so the library only knows where the current one is.

On the Mac and Windows we have the CCAPI which maintains a list of the 
existing CCAPI-based caches called the "cache collection".  Caches in 
the cache collection are just like ticket ccaches: they have a name 
(the thing KRB5CCNAME would be set to), a default client principal and 
a list of tickets.  Since there is a list of all the ccaches the user 
has put tickets in, we can just search it.

The CCAPI is being made cross-platform, so at some point soon the CCAPI 
should become available on platforms which currently use only 
file-based caches.



The Questions:


1) Do users need the ability to be able to switch between two TGTs with 
the same client principal?

For example:  A user has obtained both a forwardable and a 
non-forwardable TGT for user at DOMAIN.COM.  If the user wants to be able 
to choose whether the TGT used by a particular Kerberos operation is 
forwardable, then the answer would be "yes".


2) When searching through TGTs, what kind of control would the user 
want?  Obviously we want to be able to turn searching off, but do we 
want something finer-grained?  In particular:

	a) Would the user want to only search a subset of their TGTs?
	(eg: "null instance tickets" or "tickets for realm 'DOMAIN.COM'")

	b) Would the user want to switch between subsets which share elements?
	(eg: "null instance tickets" and "tickets with name 'foo'"
	would both contain the TGT for "foo at DOMAIN.COM")

Note that I'm not suggesting that we implement this fine-grained 
control in the first revision of this support, but I would like to 
avoid designing a system that can't be modified later to give the user 
the control they want.


3) How many different non-cross-realm client principals do users 
usually get?  How many service tickets do users usually get per client 
principal?  If you envision larger numbers in the near future, use 
those instead.

The reason I'm asking this is so that our design will be efficient even 
for large numbers of different client principals and large numbers of 
service tickets.  We've gotten bug reports about CCAPI performance on 
the Mac from folks who were testing with 250 service tickets.  Is that 
something a user might actually do?


4) Would it be acceptable to only implement the searching for 
CCAPI-based caches and just leave the file-based cache behavior as is?

Note that CCAPI-based ccaches need not be in-memory.  We could 
implement a file-based backend to the CCAPI, but it would probably not 
be compatible with the existing file-based cache format.


--lxs
-----------------------------------------------------------------------
Alexandra Ellwood                                           lxs at mit.edu
MIT Information Services & Technology           http://mit.edu/lxs/www/
-----------------------------------------------------------------------