JDK-8208299 : Provide a way to clear NegotiateAuthentication cache
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 8u172
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-07-26
  • Updated: 2018-07-27
Related Reports
Relates :  
Description
I'm using a JavaFX WebView that targets an URL that returns a 401 with the negotiate header. Thus we try to generate a kerberos ticket.

But since the allowtgtsessionkey is set to 0. We are unable to generate it ( see JDK-6722928).
Nevertheless, there is a fallback on my BasicAuthenticator in order to provide credentials to generate the kerberos ticket. 

But if the credentials are wrong, the NegotiateAuthentication class puts the returned value into its "supported" hashmap.
So the user quits the authentication process, and retries. The user wants to retry the Negotiate phase with Kerberos in order to provide the right credentials. But this snippet in NegotiateAuthentication prevents the system to retry, the cache value is retrieved :

String hostname = hci.host;
        hostname = hostname.toLowerCase();
        if (supported.containsKey(hostname)) {
            return supported.get(hostname);
        }

We should have an API allowing the develop per to clear this cache in order to force the system to retry Negotiate authentication through Kerberos.
Comments
Indeed caching the hostname together with the credentials (or hash) is a better option. In that way, you're caching a real attempt or you'll allow another attempt with another credential for the same hostname. The technical difficulty is to retrieve this hash back in NegotiateAuthentification.java. As you have seen in my capture, there are lots of calls between the NegotiateAuthentication.java and the BasicAuthenticator providing the credentials...
27-07-2018

Or maybe we can change the cache key to be a combination of hostname and credentials (or a hash).
27-07-2018

Exactly. If we were able to clear this cache, when the user tries to connect again, the whole initial logic (see the capture) would be available again and it would fallBack into the basicAuthenticator, allowing the end user to input its credentials again.
27-07-2018

You mean the application can connect again and this time allow BasicAuthenticator to provide different username/password?
27-07-2018