What do you want from your credentials cache? (was Credential cache searching, ccapi and file caches)
lxs at MIT.EDU
Wed Jul 14 14:56:37 EDT 2004
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
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
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
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.
Alexandra Ellwood lxs at mit.edu
MIT Information Services & Technology http://mit.edu/lxs/www/
More information about the krbdev