What do you want from your credentials cache? (was Credential cache searching, ccapi and file caches)
kenh at cmf.nrl.navy.mil
Thu Jul 15 13:24:25 EDT 2004
(Note; this is just my $0.02, based on my experience and what our users
need; obviously other sites have a different perspective).
>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".
I would say that the answer to this is most likely "no". While we do
have the situation where a user could have two different TGTs with
different rights (hardware preauth comes to mind), typically the
rights you add never subtract your priviledges. E.g., gaining a ticket
with hardware preauth doesn't exclude you from doing anything.
Given that, and I think the average user would be confused on which
TGT they _should_ use, I'm not sure this capability is necessary.
(But I could be proven wrong).
>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.
I have a feeling (which I don't think I can back up with any facts) that
having different search algorithms would be confusing for a user. I
suspect they'll want two settings in practice: "Find the right TGT for me
auto-magically", and "Use this principal explicitly".
>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?
I could see that being done in some environments. But ... FWIW, our
typical usage is probably 3-4 client principals and 8-10 service tickets.
>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.
Hmmm ... I guess I see a compatibility problem with different library
versions if the FILE: format changes. So not doing it for the current
FILE ccache and just doing it for CCAPI seems okay to me.
More information about the krbdev