Credential collections

Ken Raeburn raeburn at MIT.EDU
Thu Mar 24 00:32:19 EDT 2011

On Mar 23, 2011, at 16:27, Nico Williams wrote:
> So, the problem with ccache collections is that they really bleed into
> the UI.  Why should the user have to be aware of per-principal ccaches
> and then, on top, a collection of those, when the user only really
> cares about the TGTs they have, not the cached non-initial/non-TGT
> tickets?

Since this is already working on Mac OS X and has been for some time, perhaps that's the UI to look at.  (Or Network Identity Manager under Windows.)  The GUI shows you the list of principals and when your (initial) authenticators expire.  Most of the time you don't really need much else, unless you're trying to debug a problem.  Having an abbreviated version of klist that did the same from the CLI would be handy.

> One answer might be that the user might want to use subsets of
> credentials for different applications.

Oh, it goes further than that.  When I run it needs to use my ATHENA.MIT.EDU credentials to fetch my MIT email, and my RAEBURN.ORG credentials to fetch my home email, all in one process; the "select different credentials for different process groups" approach is insufficient; so is always using the default principal, with a command-line tool to select a new default.  The KIM API is intended to address this sort of thing -- let you map from application, server name, account name, etc., to one of your Kerberos identities.  See for example and .


More information about the krbdev mailing list