directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Lamb" <>
Subject Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.
Date Mon, 08 May 2017 09:08:34 GMT

Hi all

I hope this is the appropriate mailing list for this type of question. Or
would it be better on the Directory Developers’ list?

I am considering using Kerby kerb-client as an alternative to Java GSS-API
for a Java client application in a Kerberos single sign on environment.

In my proof of concept setup I am using FreeIPA clients and servers.  When
the user logs on to his workstation he is authenticated by the FreeIPA KDC,
and  gets a TGT which is cached in the default credentials cache. When he
wishes to access services from the application server (which is a Service
Principal), the TGT in the credentials cache is used to get a Service
Ticket, which should also be cached in the credentials cache for future

With a throwaway Python GSS-API client this worked perfectly. "klist" shows
both the TGT and the SGT in the credentials cache. But trying to do the
same thing with Java GSS-API I ran into problems. While the Client is able
to retrieve a Service Ticket, and thus login to the Service Principal, the
SGT is not cached. Thus every request to the Service Principal requires KDC
interaction. Not good.

In my search for alternatives, I came across Kerby kerb-client, and am
experimenting with it, but so far without success despite much debugging
and scanning of Kerby code.

Here is the question: Can the Kerby kerb-client be configured to access an
existing Kerberos credential cache (as opposed to a KeyTab), and to use the
TGT ticket within, and to cache new service tickets? In this case the
existing credentials cache is from

So far I have found no config to do so. Searching through the Kerby code I
find references to things like  ‘credCache’, ‘KRB5_CACHE’, ‘ARMOR_CACHE’.
However in AbstractInternalKrbClient.requestTGT() I can’t find any USE_xxx
options that seem appropriate for using a credentials cache.

Have I missed something obvious? If so, which options should I be


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message