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:
https://stackoverflow.com/questions/43786908/java-gss-api-service-ticket-not-saved-in-credentials-cache-using-java
Note the code in the solution is simplified (e.g. no checks on
isContextEstablished).
And my Kerby question:
https://www.mail-archive.com/kerby@directory.apache.org/msg00952.html
Cheers
Chris
-----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
Hi,
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();
config.enableDebug();
KrbClient client = new KrbClient(config);
client.setKdcHost("ADHOST");
client.setKdcTcpPort(88);
//client.setAllowUdp(false);
client.setKdcRealm("Realm");
client.init();
TgtTicket tgt;
SgtTicket sgt;
tgt = client.requestTgt("user", new File("krb5.keytab"));
sgt = client.requestSgt(tgt, "HTTP/test.example.com");
} catch (KrbException e1) {
e1.printStackTrace();
}
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:
KDC_ERR_ETYPE_NOSUPP
Which I'm guessing means I need to configure some settings for
supported encrption types.
Does Kerby cache SGTs?
Thanks,
Shane
