[krbdev.mit.edu #6206] storing configuration data in credentials caches

[Greg Hudson]

On Tue, 2009-09-01 at 14:40 -0400, Sam Hartman wrote:
> I agree with Jeff that the implementation is kind of ugly.  However I
> don't want to see us get into a situation where perfect is the enemy
> of progress.  In particular, Jeff's proposal seems difficult to
> implement for file based ccaches.

Love's implementation operates at the generic ccache layer.  A way to
address Jeff's concerns is to push the decision into the ccache
provider.  Then, file ccaches can continue to work the way they do in
Love's patch, CCAPI ccaches can use the existing type field, and memory
ccaches can grow a new type field to properly isolate configuration from
ticket entries.

However, when we discussed this option at a recent meeting, we were not
sure the benefit outweighs the cost, which is twofold: (1) it's
noticeably more work, and (2) it's incompatible with CCAPI-using
deployments of Love's implementation under OSX, assuming those exist.

The major practical downside to using magic service principals is that
old code might try to display configuration entries to users, which
would be confusing (the entries should display okay since the
configuration data is stored in the normally-opaque key field, but would
still be unwanted gunk in the list).  This is probably more likely in a
CCAPI world than a Unix file-based ccache world since Unix ccache access
is usually funneled through the system libkrb5.

I do not have strong objections to either approach.