Re: Caching
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 Clementswrote: - To: kerby@directory.apache.org From: Shane Clements 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
Re: Using Kerby kerb-client as an alternative for GSS-API.... Sgt Request fails
msg-type: krb-ap-req (14) Padding: 0 ap-options: 0... = reserved: False .0.. = use-session-key: False ..0. = mutual-required: False ticket tkt-vno: 5 realm: ACME.COM sname name-type: kRB5-NT-PRINCIPAL (1) sname-string: 2 items SNameString: krbtgt SNameString: ACME.COM enc-part etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) kvno: 1 cipher: c2da50b960fdfdc44e098ee243f0aa698cfad82b8867fb98... authenticator etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) cipher: 5e944cb16b72c6cb12b830b91e83ca84b3b7eadfb364e7da... req-body Padding: 0 kdc-options: 5001 (forwardable, proxiable, canonicalize) 0... = reserved: False .1.. = forwardable: True ..0. = forwarded: False ...1 = proxiable: True 0... = proxy: False .0.. = allow-postdate: False ..0. = postdated: False ...0 = unused7: False 0... = renewable: False .0.. = unused9: False ..0. = unused10: False ...0 = opt-hardware-auth: False ..0. = request-anonymous: False ...1 = canonicalize: True 0... = constrained-delegation: False ..0. = disable-transited-check: False ...0 = renewable-ok: False 0... = enc-tkt-in-skey: False ..0. = renew: False ...0 = validate: False cname name-type: kRB5-NT-PRINCIPAL (1) cname-string: 1 item CNameString: lamb realm: ACME.COM sname name-type: kRB5-NT-PRINCIPAL (1) sname-string: 2 items SNameString: HTTP SNameString: app-srv.acme.com from: 2017-05-09 04:42:12 (UTC) till: 2017-05-09 12:42:12 (UTC) nonce: 589063260 etype: 3 items ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23) ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) Thanks Chris From: Christopher Lamb/Switzerland/IBM@IBMCH To: kerby@directory.apache.org Date: 08/05/2017 18:43 Subject:Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Kai With the following code I can successfully retrieve a TGT from my existing credential cache and use it to request a service ticket!. Unfortunately the Service Ticket Request is currently failing with "KDC cannot accommodate requested option". private TgtTicket retrieveCachedTicket(File ccacheFile) throws KrbException { Ticket ticket = null; PrincipalName clientPrincipal = null; EncAsRepPart encKdcRepPart = null; if (ccacheFile.exists() && ccacheFile.canRead()) { CredentialCache cCache = new CredentialCache(); try { cCache.load(ccacheFile); List credentials = cCache.getCredentials(); for (Credential cred : credentials) { //we only want a tgt if (cred.getServerName().toString().startsWith("krbtgt")) { ticket = cred.getTicket(); clientPrincipal = cred.getClientName(); encKdcRepPart = new EncAsRepPart(); encKdcRepPart.setAuthTime(cred.getAuthTime()); encKdcRepPart.setCaddr(cred.getClientAddresses()); encKdcRepPart.setEndTime(cred.getEndTime()); encKdcRepPart.setFlags(cred.getTicketFlags()); encKdcRepPart.setKey(cred.getKey()); //encKdcRepPart.setKeyExpiration(); //no method to get from cred //encKdcRepPart.setLastReq(); //no method to get from cred //encKdcRepPart.setNonce(); //no method to get from cred encKdcRepPart.setRenewTill(cred.getRenewTill()); encKdcRepPart.setSname(cred.getServerName()); encKdcRepPart.setSrealm(cred.getServerName().getRealm()); encKdcRepPart.setStartTime(cred.getStartTime()); } } } catch (IOException e) { throw new KrbException("Failed to load credentials", e); } } else { throw new IllegalArgumentException("Invalid ccache file, " + "does not exist, or is not readable: " + ccacheFile.getAbsolutePath()); } return new TgtTicket(ticket, encKdcRepPart, clientPrincipal); } private void getKerbyServiceTicket() { try { File confFileDir = new File("/home/lamb/OTMS/kerberosTesting/"); KrbClient krbClient = new KrbClient(confFileDir); krbClient.setKdcHost("kdc.acme.com"); krbClient.setAllowUdp(true); krbClient.setAllowTcp(true
Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.
...@acme.com for HTTP/app-srv.acme@acme.com Cheers Chris From: "Zheng, Kai" <kai.zh...@intel.com> To: "kerby@directory.apache.org" <kerby@directory.apache.org> Date: 08/05/2017 14:32 Subject:Re: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Got your point. Please read credential cache utility codes and see if any API doing so. Sent from iPhone 在 2017年5月8日,下午8:13,Christopher Lamb <christopher.l...@ch.ibm.com< mailto:christopher.l...@ch.ibm.com>> 写道: Hi Kai Browsing further through the kerby code, I think I need the opposite of KrbClientBase.storeTicket(): for instance a " Public TgtTicket retrieveCachedTicket(File ccacheFile)" Let me see if I can knock something together based on storeTicket() Cheers Chris [Inactive hide details for "Zheng, Kai" ---08/05/2017 13:09:19---If I remember correctly, it first generates a cache with a TGT,]"Zheng, Kai" ---08/05/2017 13:09:19---If I remember correctly, it first generates a cache with a TGT, then do the login test with the tick From: "Zheng, Kai" <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" <kerby@directory.apache.org<mailto:kerby@directory.apache.org>> Date: 08/05/2017 13:09 Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. If I remember correctly, it first generates a cache with a TGT, then do the login test with the ticket cache. In your case, you would need to know where is the cache file and point it to Kerby client, as the test did. Regards, Kai From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] Sent: Monday, May 08, 2017 7:05 PM To: kerby@directory.apache.org<mailto:kerby@directory.apache.org> Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Kai Thanks, example code is always best. TicketCacheLoginTest looks like part of the answer, especially the storeTicket() function. However (unless I have completely misread the test-case), the TGT is not retrieved from the cache, it is only stored there. In my Single-Sign-On case, the user already has a TGT, which was obtained on log in to the workstation (or by kinit), prior to starting my java client. I am assuming it should be possible for kerby to use the existing TGT. Cheers Chris [Inactive hide details for "Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in]"Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in the parent one. From: "Zheng, Kai" <kai.zh...@intel.com<mailto:kai.zh...@intel.com>< mailto:kai.zh...@intel.com>> To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>< mailto:kerby@directory.apache.org>" <kerby@directory.apache.org< mailto:kerby@directory.apache.org><mailto:kerby@directory.apache.org>> Date: 08/05/2017 12:45 Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Chris, Both dev list should be OK as Kerby folks are also in the parent one. I haven't read your details fully (will do it later), but would make sure if you have already checked out the test of TicketCacheLoginTest in the kerby code base. In one word, Kerby client surely can consume and use a credential cache generated by other tools like MIT kinit. If you see any issue, please report it. Regards, Kai -Original Message- From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] Sent: Monday, May 08, 2017 5:09 PM To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>< mailto:kerby@directory.apache.org> Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. 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 use. 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
RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.
Hi Kai Browsing further through the kerby code, I think I need the opposite of KrbClientBase.storeTicket(): for instance a " Public TgtTicket retrieveCachedTicket(File ccacheFile)" Let me see if I can knock something together based on storeTicket() Cheers Chris From: "Zheng, Kai" <kai.zh...@intel.com> To: "kerby@directory.apache.org" <kerby@directory.apache.org> Date: 08/05/2017 13:09 Subject:RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. If I remember correctly, it first generates a cache with a TGT, then do the login test with the ticket cache. In your case, you would need to know where is the cache file and point it to Kerby client, as the test did. Regards, Kai From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] Sent: Monday, May 08, 2017 7:05 PM To: kerby@directory.apache.org Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Kai Thanks, example code is always best. TicketCacheLoginTest looks like part of the answer, especially the storeTicket() function. However (unless I have completely misread the test-case), the TGT is not retrieved from the cache, it is only stored there. In my Single-Sign-On case, the user already has a TGT, which was obtained on log in to the workstation (or by kinit), prior to starting my java client. I am assuming it should be possible for kerby to use the existing TGT. Cheers Chris [Inactive hide details for "Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in]"Zheng, Kai" ---08/05/2017 12:45:22---Hi Chris, Both dev list should be OK as Kerby folks are also in the parent one. From: "Zheng, Kai" <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> To: "kerby@directory.apache.org<mailto:kerby@directory.apache.org>" <kerby@directory.apache.org<mailto:kerby@directory.apache.org>> Date: 08/05/2017 12:45 Subject: RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Chris, Both dev list should be OK as Kerby folks are also in the parent one. I haven't read your details fully (will do it later), but would make sure if you have already checked out the test of TicketCacheLoginTest in the kerby code base. In one word, Kerby client surely can consume and use a credential cache generated by other tools like MIT kinit. If you see any issue, please report it. Regards, Kai -Original Message- From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] Sent: Monday, May 08, 2017 5:09 PM To: kerby@directory.apache.org<mailto:kerby@directory.apache.org> Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. 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 use. 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 configuring? Thanks Chris
RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.
Hi Kai Thanks, example code is always best. TicketCacheLoginTest looks like part of the answer, especially the storeTicket() function. However (unless I have completely misread the test-case), the TGT is not retrieved from the cache, it is only stored there. In my Single-Sign-On case, the user already has a TGT, which was obtained on log in to the workstation (or by kinit), prior to starting my java client. I am assuming it should be possible for kerby to use the existing TGT. Cheers Chris From: "Zheng, Kai" <kai.zh...@intel.com> To: "kerby@directory.apache.org" <kerby@directory.apache.org> Date: 08/05/2017 12:45 Subject:RE: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. Hi Chris, Both dev list should be OK as Kerby folks are also in the parent one. I haven't read your details fully (will do it later), but would make sure if you have already checked out the test of TicketCacheLoginTest in the kerby code base. In one word, Kerby client surely can consume and use a credential cache generated by other tools like MIT kinit. If you see any issue, please report it. Regards, Kai -Original Message- From: Christopher Lamb [mailto:christopher.l...@ch.ibm.com] Sent: Monday, May 08, 2017 5:09 PM To: kerby@directory.apache.org Subject: Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On. 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 use. 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 configuring? Thanks Chris
Using Kerby kerb-client as an alternative for GSS-API for Kerberos Single Sign On.
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 use. 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 configuring? Thanks Chris