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