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

[Ken Hornstein]

(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 
>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?

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.

--Ken