Hi Shane
I was asking my self very similar questions last year, also in combination with 
WebServices. I spent considerable time debugging the Java 8 Runtime Kerberos 
security classes, and sniffing Kerberos API calls on the wire with Wireshark!
I also experimented with Kerby as an alternative to Java GSS - which is why I 
joined this list! Unfortunately I got stuck with Kerby too. As luck with have 
it, I got an acceptable solution with Java GSS first; and therefore did not 
hunt further with Kerby, but it is quite possible that the problems I had with 
Kerby are solvable, or have been fixed in the meanwhile.
>From my point of view, the real problem is not that Java does not store 
>Tickets in the default ticket cache: that is a symptom. The real problem is 
>that as a result, your client may be hammering the KDC(s) with repeated SGT 
>ticket requests, potentially on every WebService api call.
After much experimentation and hours of debugging, I got a working solution 
with Java GSS. While the SGT ticket is still not stored in the cache, it can be 
stored in the GSS Context Credentials (think of this as an in application 
cache). Thus for the first api call (e.g. for Login) my client will hit the 
KDC, but all further api calls with use the ticket from the GSS credentials 
without any further KDC interaction.
Other helpful souls in various forums suggested that Kerberos could be used for 
the first api call only: Once the client has successfully authenticated using 
Kerberos a lighter weight mechanism could be used for subsequent calls.
However I think this adds complication, and some testing would be required to 
prove that “lighter weight” mechanism is secure, and importantly really lighter 
weight / performant than Kerberos.
In my final implementation we use a Kerberos hardened WebService call first. If 
authentication is successful, we then set up a Kerberos hardened WebSocket 
(which we require anyway for unsolicited messages from the Server to the 
Client), and then use the WebSocket for all further API calls.
The WebSocket uses Kerberos authentication during the handshake promotion from 
HTTPS to WSS, but not for messages over the established connection (though we 
thinking of optionally adding this).
You will find my StackOverflow question (and answer) on this topic below:
Note the code in the solution is simplified (e.g. no checks on 
And my Kerby question:

-----Shane Clements <shane.cleme...@gmail.com> wrote: -----
To: kerby@directory.apache.org
From: Shane Clements <shane.cleme...@gmail.com>
Date: 03/06/2018 10:35PM
Subject: Caching


I'm wondering if Kerby might be a solution to a problem that I am
having. As I understand it, Java 1.7 libraries for working with
KDC/Kerberos do not cache service tickets.

I was trying a toy program to see if I could cache a service ticket
with Kerby library:

try {

  KrbConfig config = new KrbConfig();
  KrbClient client = new KrbClient(config);


  TgtTicket tgt;
  SgtTicket sgt;

  tgt = client.requestTgt("user", new File("krb5.keytab"));
  sgt = client.requestSgt(tgt, "HTTP/test.example.com");

} catch (KrbException e1) {



Incidentally, is there docs about configuring the client as I always
get (against a real KDC)

org.apache.kerby.kerberos.kerb.KrbException: null with error code:

Which I'm guessing means I need to configure some settings for
supported encrption types.

Does Kerby cache SGTs?



Reply via email to