[security-dev 01000]: Re: CCAPI in Java

[Shawn M Emery]

Weijun Wang wrote:
> Hi Shawn
>
> Earlier this year, you've asked me about supporting CCAPI in Java. At
> the time, our Java JGSS provider only support the FILE ccache reading.
> (We do have a native bridge to GSSAPI but that provider is not turned on
> by default).
>
> I'm creating a native bridge to CCAPI now.
>
> Some questions:
>
> 1. How can I create a non-FILE ccache for a test?
>   

Yes, you can use the MEMORY cc type in order to do this.  It is per 
process memory, which has special use cases for temporary storage of 
credentials.

> 2. How likely is that a non-FILE ccache will be used in practice
> nowadays? Currently the Java build machine of Solaris is still S10 6/06.
>   

This MEMORY cc type is used in number of places withing the krb5 mech.

> Since Kerberos 5 API are introduced in S10 8/07, I need a strong reason
> to persuade the release team to upgrade or add krb5.h to the building
> environment.
>   

I haven't completed the implementation for the CCAPI (session memory 
ccaches) and I'm not for certain that this would even be the default 
type once implemented.

> 3. I'm writing my codes based on the klist program in MIT krb5-1.7,
> which include calls to these functions:
>
>     krb5_init_context
>     krb5_cc_default
>     krb5_cc_get_name
>     krb5_cc_get_type
>     krb5_cc_set_flags
>     krb5_cc_start_seq_get
>     krb5_cc_next_cred
>     krb5_unparse_name
>     krb5_free_unparsed_name
>     krb5_free_cred_contents
>     krb5_cc_end_seq_get
>     krb5_free_context
>
> How about the compatibility of these functions with previous/other
> versions of krb5? Since JGSS already supports reading FILE ccache, I
> won't care about the old krb5 versions that also only supports FILE ccache.
>   

The interface is designed for ccache plugins, so if applications no 
longer worked with the introduction of a new type then this would be a 
bug in the mech and would get fixed.

Shawn.
--