Java is a pretty complicated topic. The compatibility with authentication is very much depending on the application. Java allows to use pre-defined functions to talk to a proxy or a web server, but in Java you can also create this code on your own. There are even Java Apps which do not respect proxy settings at all.
While working for support I have seen dozens of Java Applications working perfectly fine with Web Gateway, and dozes which did not, because they sent malformed authentication headers, or did not react on a 407 MWG replied to trigger authentication. Others only support basic authentication, etc.
Basically, if Authentication is working find from your browser, it should work find with the Java Application as well, as long as it correctly deals with authentication. What you can try to do is adding your Domain to your AD credentials, e.g. DOMAIN\username + adding the correct password. The browser usually does this step automatically.
If that does not help, but you can use those credentials when browsing, I think it would be helpful to file a support ticket, and add a packet capture and a feedback. We will then be able to determing whether this is a problem of MWG or the Java Application and provide help solving the issue.
If a quick solution is required, you may want to try to whitelist the Java Application from Authentication, which should allow you to use it immediatly.
We have tried to enter domain\username into the auth prompt to no avail. We are not sure what credentials it is looking for, and we see nothing in the logs related to auth failure.
We have a ticket open with support on this issue as well. I also see a few other discussion related to java apps, so it seems to be a common issue.
How do I whitelist a java app from authentication? I only see where I can skip auth for URL's that are in a white list
I would suggest you check the access.log and see how the requests coming from the Java App look like. Most likely you will see that it tries to access the same URL (in this case you can whitelist the URL). Even better would be a custom User-Agent, which is also in the logs usually. In this case you can add an exception for the User-Agent to the authentication.
You can access the User-Agent header with the Header.Request.Get("User-Agent") property.
This would be the easiest approach, but should be seen as a workaround only. You should work with support to get the authentication issue solved in parallel.
Thanks for all the help guys.
I was able to create the user-agent rule such that the string mentioned in the access.log would no longer prompt for authentication.