Details
Major Description
In the Login class, a background thread is started that periodically performs a re-login to the Kerberos Ticket Granting Server.
For the initial login, a custom Configuration instance is created and supplied to the LoginContext constructor potentially using a custom JAAS file location.
However, the background refresh thread does not then subsequently provide the JAAS file location or Configuration to the reLogin method, so it tries to construct a LoginContext with just a context name and subject but no Configuration parameter, which means that the underlying Configuration.getConfiguration() call has to load one from system defaults, which could possibly specify a different file or none at all.
In our application where this issue was found, we had set the java.security.auth.login.config value to a valid JAAS file location as a Storm client property along with other standard connectivity properties, since the Netty client framework loads it from the topology configuration. It looks like the Netty server framework does the same as well. The initial login succeeded and the following Storm Nimbus interactions were successful, but a while later it lost the ability to communicate with Storm with this error being logged,
ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh TGT for principal: <REDACTED> javax.security.auth.login.LoginException: No LoginModules configured for StormClient at java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267) at java.base/javax.security.auth.login.LoginContext.<init>(LoginContext.java:385) at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409) at org.apache.storm.messaging.netty.Login$1.run(Login.java:222) at java.base/java.lang.Thread.run(Thread.java:829)
It appears that a viable workaround for this issue is to also set the system property,
-Djava.security.auth.login.config=/some/path/jaas.conf
for the application, referencing the same JAAS file location as was set in the Storm configuration. After doing so the background refresh thread was able to correctly function in our situation.
To address this, we can update the reLogin method to use the same JAAS configuration. Furthermore it should use the same callback handler instance that was originally provided also, instead of creating a new default one.
