| Subject: | gss_store_cred should initialize ccache and work with collections |
gss_store_cred is specified in RFC 5588 and has been implemented since
1.8. It is intended to allow delegated creds received from
gss_accept_sec_context to be stored for use by other processes. It
accepts a GSS credential object and two flags, overwrite_cred and
default_cred. The overwrite_cred flag controls whether credentials for
the same principal should be overwritten, and the default_cred flag
controls whether the stored credentials should be made available as the
default.
The current cache selection behavior of gss_store_cred is not terribly
helpful:
* If default_cred is false, error out.
* Resolve the initial ccache using krb5int_cc_default. This function
acquires tickets interactively on Windows if there aren't any present,
which is clearly undesirable.
* If overwrite_cred is false and we can successfully acquire creds with
the krb5 gss_acquire_cred, error out. acquire_cred is called with a
desired_name of the cred's name unless default_cred is set, in which case
it is called with no specific name. This is not very robust given all of
the changes to gss_acquire_cred since 1.8; it will error out if a client
keytab is available.
* Store Kerberos credentials from the GSS cred object into the cache. If
the cache is uninitialized, this will fail with a confusing error.
Heimdal's behavior is:
* If the collection contains a cache for the principal, store the creds
there. Otherwise create a new unique cache.
* If default_cred is true, switch to the selected cache.
This behavior does not respect overwrite_cred. It also does not
gracefully handle the case where the default cache is not a collection,
unless that cache is already initialized with the principal of the GSS
cred object.
The Solaris behavior is:
* Check if we can acquire creds with gss_acquire_cred (similar to the
current MIT krb5 behavior). If we can, error out if overwrite_cred is
false.
* Resolve the default ccache with krb5_cc_default.
* If default_cred is false, error out. (There is a long comment
explaining what the code could otherwise do, but it predates cache
collection support and explains that performance would not scale well.)
* Initialize the ccache with the name of the GSS credential.
* Store Kerberos credentials from the GSS cred object into the cache.
We should implement behavior similar to Heimdal's (modified to respect
overwrite_cred) if the default cache name is a collection, and the
Solaris behavior if it is not.
Since 1.11 we have supported gss_store_cred_into, which can accept a
ccache name via its cred_store parameter. If a ccache name is specified,
that name is resolved and initialized. We should preserve this behavior
when the specified ccache name is not a collection; if it is a
collection, we should use the same collection semantics as we would if
the default ccache name is a collection.
1.8. It is intended to allow delegated creds received from
gss_accept_sec_context to be stored for use by other processes. It
accepts a GSS credential object and two flags, overwrite_cred and
default_cred. The overwrite_cred flag controls whether credentials for
the same principal should be overwritten, and the default_cred flag
controls whether the stored credentials should be made available as the
default.
The current cache selection behavior of gss_store_cred is not terribly
helpful:
* If default_cred is false, error out.
* Resolve the initial ccache using krb5int_cc_default. This function
acquires tickets interactively on Windows if there aren't any present,
which is clearly undesirable.
* If overwrite_cred is false and we can successfully acquire creds with
the krb5 gss_acquire_cred, error out. acquire_cred is called with a
desired_name of the cred's name unless default_cred is set, in which case
it is called with no specific name. This is not very robust given all of
the changes to gss_acquire_cred since 1.8; it will error out if a client
keytab is available.
* Store Kerberos credentials from the GSS cred object into the cache. If
the cache is uninitialized, this will fail with a confusing error.
Heimdal's behavior is:
* If the collection contains a cache for the principal, store the creds
there. Otherwise create a new unique cache.
* If default_cred is true, switch to the selected cache.
This behavior does not respect overwrite_cred. It also does not
gracefully handle the case where the default cache is not a collection,
unless that cache is already initialized with the principal of the GSS
cred object.
The Solaris behavior is:
* Check if we can acquire creds with gss_acquire_cred (similar to the
current MIT krb5 behavior). If we can, error out if overwrite_cred is
false.
* Resolve the default ccache with krb5_cc_default.
* If default_cred is false, error out. (There is a long comment
explaining what the code could otherwise do, but it predates cache
collection support and explains that performance would not scale well.)
* Initialize the ccache with the name of the GSS credential.
* Store Kerberos credentials from the GSS cred object into the cache.
We should implement behavior similar to Heimdal's (modified to respect
overwrite_cred) if the default cache name is a collection, and the
Solaris behavior if it is not.
Since 1.11 we have supported gss_store_cred_into, which can accept a
ccache name via its cred_store parameter. If a ccache name is specified,
that name is resolved and initialized. We should preserve this behavior
when the specified ccache name is not a collection; if it is a
collection, we should use the same collection semantics as we would if
the default ccache name is a collection.