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