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. --
