get_cred starting realm

[Nico Williams]

On Wed, Apr 29, 2015 at 01:01:45PM -0400, Benjamin Kaduk wrote:
> On Wed, 29 Apr 2015, Nico Williams wrote:

> "What if the creator of a new FILE: ccache is a java application?"

Then whatever knowledge of "start realm" was always going to be lost,
and will continue to be lost until the application is enhanced.  Interop
with such an app continues using traditional behavior (see below).

Picking a start realm at kinit time (e.g., the Java application is using
Kerberos via a JNI interface) helps.

And if the Java application is using native Java Kerberos then we
fallback on the same old behavior: use a TGT for the client principal's
realm.

Because Heimdal (and hopefully soon MIT) had to interop with writers of
ccaches that don't store this ccconfig, the correct behavior is to
fallback on the pre-start-realm-ccconfig behavior when that ccconfig is
missing.  That's what I implemented for Heimdal.

To recap:

 - maximum interop:

   - readers that need a starting-realm notion look for the new
     start-realm ccconfig using krb5_cc_get_config()

     if the find it, they use that, else the do what they always did
     (use the client principal's realm name as the starting realm)

 - reasonable default start realm selection at kinit time:

   - krb5_cc_initialize() marks the ccache as needing a starting realm

   - krb5_cc_store_cred() on an initialized ccache picks the first local
     TGT's realm as the starting realm and stores that in a start-realm
     ccconfig, then clears the flag set by krb5_cc_initialize()

 - application-level knowledge of starting realm is honored:

   - krb5_cc_store_cred() always allows the application to store a
     start-realm ccconfig (usually via krb5_cc_set_config(), of course)
     to override the default start-realm selection

> The LSA itself permits insertion; our MSLSA interface to it may not be
> quite so generous, though I don't remember offhand.

Does it permit storing of ccconfigs?  (That would be handy.)

Nico
--