krb5 cc iteration and selection functions

[Alexandra Ellwood]

On Oct 28, 2005, at 9:20 AM, Love wrote:

>
> Hello,
>
> I extended the krb5_cc api for Heimdal recently to support  
> iteration and
> cache selection. Jeffery Altman asked me to post about them here.
>
> I've written about why they are useful here:
> http://blogs.su.se/lha/Heimdal/20051021182400.1129911904771.html
>
> Some question that jeff rasied, and I punted on when I did the
> implementation because it was simpler, is that the NULL type is  
> suppsed to
> do. Really it should probably iterate over all caches.
>
> Love
>
>
> /*
>  * Start iterating over all caches of `type'. If `type' is NULL, the
>  * default type is * used. `cursor' is initialized to the beginning.
>  * Return 0 or an error code.
>  */
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_get_first (krb5_context context,
>              const char *type,
>              krb5_cc_cache_cursor *cursor)
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_next (krb5_context context,
>            krb5_cc_cache_cursor cursor,
>            krb5_ccache *id)
>
> /*
>  * Destroy the cursor `cursor'.
>  */
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_end_seq_get (krb5_context context,
>                krb5_cc_cache_cursor cursor)
>

These functions look fine to me.  We needed to do this anyway.  :-)

I do agree with Jeff that if there are multiple ccache types available
that NULL should iterate over all of them.  This is especially important
for KfW (which has the LSA and API types), and for Linux (which will  
have
keyring and API types in the future).


>
> /*
>  * Search for a matching credential cache of type `type' that have the
>  * `principal' as the default principal. If NULL is used for `type',
>  * the default type is used. On success, `id' needs to be freed with
>  * krb5_cc_close or krb5_cc_destroy. On failure, error code is
>  * returned and `id' is set to NULL.
>  */
>
> krb5_error_code KRB5_LIB_FUNCTION
> krb5_cc_cache_match (krb5_context context,
>              krb5_principal client,
>              const char *type,
>              krb5_ccache *id)

This function appears to do almost (but not quite) the same thing as  
one of
the mostly commonly used code paths in the Kerberos Login Library (KLL).

The big difference is that the KLL usually needs to find the first cache
containing *valid* initial tickets for a given client principal.  By  
valid I
mean non-expired, ip-address-matching, non-needs-validation tickets.   
If no
valid tickets exist then the KLL tries renewing/validating the first  
invalid
ones it finds.  If the KLL can't renew and the application is a GUI  
app, it
tries to prompt the user for more tickets.

Since there may be multiple ccaches with the same client principal in  
them
(especially if you change the NULL type to mean search over all  
types), the
KLL can't use this function.  What it really needs is either for this  
function
to return an array of krb5_ccaches that match the client principal or  
to also
check validity.  The latter seems like a bad idea because none of the  
other
krb5_cc_* functions deal with validity.

Obviously the existence of this function doesn't stop me from  
implementing my
KLL algorithm using the iterators above.  However since the KLL's  
algorithm will
share a lot of code in common with this one, I wonder if we need  
both.  I'd
recommend keeping this function internal (I assume you're using it to  
implement
your gss_acquire_cred support) and then implementing the new KLL one  
when we
finalize the new API.  If this function has already shipped exported  
with
Heimdal, I will probably still argue in favor of MIT Kerberos not  
exporting it
unless someone can come up with a case where it's useful and the KLL  
behavior
wouldn't be more useful.

(Note that the new KLL API will be cross-platform and implemented for  
KfM, KfW
and the Unix ports of MIT Kerberos.  I will be posting a proposed API  
for it in
the next couple weeks and would be very happy if Heimdal folks  
participated in
the API review process and implemented it.)  :-)


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>