Also please note, that the 'Configuration.getConfiguration().refresh()' will reload only the jaas.config. If you also need to reload the kerberos client config, then you can add the "refreshKrb5Config=true" line to your jaas.conf file. This will trigger to reload the krb.cfg file as well if needed.
I am just working on a PR where I had to use both of these: https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a Cheers, Mate On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen <[email protected]> wrote: > > Hi Enrico, > > > There is a method to force JAAS to reload the system property. > > > > Something like Configuration.getConfiguration().refresh() > > Great to know! Thanks! > > > You have to call that method after changing the system property > > Cheers, -D > > > > > Il gio 9 gen 2020, 20:05 Damien Diederen <[email protected]> ha > > scritto: > > > >> > >> Hi Arpit, Máté, > >> > >> Arpit wrote: > >> > >> > The solution is to pass JAAS file > >> > with -Djava.security.auth.login.config=/path/to/jaas.conf. > >> > >> Okay—good. > >> > >> > Using System.setProperty does not work for me. > >> > >> Ah, I see. And I'm not surprised; I think Máté is on the right track: > >> > >> >> I also faced this exception not long ago. I think it is an edge case, > >> most > >> >> probably you have something else, but still... maybe it helps: > >> >> > >> >> I tried to write a unit test which dynamically generated multiple > >> >> jaas.conf files. Then I was setting the > >> >> java.security.auth.login.config system property to the config file I > >> needed > >> >> in the given testcase, and when I tried to establish a ZooKeeper > >> connection > >> >> in the unit test, I also got the same exception that you got. > >> >> > >> >> The problem was, that the security configuration file I referred in > the > >> >> java.security.auth.login.config system property file was read only > once, > >> >> then stored in memory. And it haven't got reloaded, even if the file > (or > >> >> its path in the system property) changed. > >> > >> My understanding is that the property is read very early after "VM boot" > >> (the first time any class tries to access the java.security.Provider): > >> the resource it points to is parsed at that point, and the property > >> "never" checked again. > >> > >> (It *may* be possible to flush the "Spi" or something, but it's clearly > >> not the kind of usage it was designed for.) > >> > >> >> Maybe the best in this case is to > >> >> specify separate JAAS config sections for each tests and use a single > >> >> JAAS.conf file per JVM. > >> > >> That's probably the easiest if the set is enumerable. > >> > >> "Real dynamism" might require overriding the "Spi" or "Provider," but > >> that's probably overkill for a few tests. > >> > >> (Now that I think of it… our tests are already run under the JMockit > >> agent, so live-patching JAAS methods using mockit.MockUp might be > >> another option :) > >> > >> Anyway. It looks like setting the property externally worked for Arpit. > >> > >> Cheers, -D > >> >
