it seems to me that wrapLocalFileUri should really be added to ProviderUtils rather than to the credential provider itself. There is a bit of a blurred line due to the fact that it creates a localjceks based URI but since it isn't part of the CredentialProvider interface and is basically needed for tests - I think it should go in either the ProviderUtils class or just be part of the test.
I'm happy to place the helper function where ever y'all would like. However, it's important to note that the wrapper is just implementing the munging described in the javadocs for LJKSP, it's not the same as the one described in ProviderUtils.unnest (though that one is a superset). I figure it ought not be a part of the specific test since it's generally useful for other tests that need to similarly test against a local jks.
Is something like ProviderUtils.nestLocalFileUriInLocalJavaKeyStoreProvider preferable?
I also just wanted to point out that the local version of the keystore provider is primarily useful when you CAN'T store the keystore in HDFS. For instance, the LDAPGroupsMapping can't use the Hadoop FileSystem abstraction because it causes a recursive infinite loop in order to look up groups to see if you can access the keystore. I just wanted to make sure that you were aware of the regular JavaKeyStoreProvider which allows for local file or hdfs.
Yep, I saw it. The test is meant to be lightweight without access to a minicluster, so it seemed best to ensure only local jks would be used.