How do I protect my JNLP, my JARs etc. (with Basic Authentication)???

Question

hi all,
i know that there is a FAQ ( [see here|http://lopica.sourceforge.net/faq.html#obfuscate] ) answering a related question with "You can use an obfuscator...". ok, but is there really no other solution?
this is the simplified folder structure of my application on the server:
[application]
  [etc]
    xyz.xml
  [jars]
    myapp.jar
  launch.jnlp
website.jsp
initial start and basic authentication:*
my first idea was to secure everything underneath "application" with basic authentication via my web.xml (yes, i'm aware of the security concerns). this means everybody can access my website (here: website.jsp) which contains a start button that links to "launch.jnlp". as soon as the user clicks on it, the browser opens its standard authentication dialog since launch.jsp is in a protected area. after entering the correct credentials the jnlp-file is downloaded and java web start takes over control. first of all it seems as it tries to access the same jnlp-file again (??? --> probably in order to check for changes in the jnlp file --> this is certainly not the case for the initial startup) and then wants to download the relevant jar (myapp.jar). because both resources are protected jws opens its own basic authentication dialog where i have to enter the same credentials the second time. as far as i know, there is no solution to pass the credentials between the browser and the jvm.
second start and basic authentication:*
if the user starts my application for the 2nd, 3rd, ... time via desktop-link (set in jnlp-file) there is no need for accessing my website with a browser. therefore only the authentication dialog of jws gets displayed. so far, so good!
and now the actual problem:*
during runtime my application (signed with verisign certificate and having all permissions) uses commons-vfs and commons-httpclient to access resources on the same server (e.g. etc/xyz.xml). since they're underneath the protected "application" directory as well, my application needs the same credentials the user already entered in the authentication dialog of jws. now i could retrieve these credentials by calling Authenticator.requestPasswordAuthentication() within my application and passing them to vfs and httpclient. however, doing so opens up jws' authentication dialog again. grrr!!! is there a way to prevent this?
related thougts:*
i know i could disable jws' default Authenticatior and set my own Authenticator which might be able to return already entered credentials without opening the dialog a second time. however, it seems that even with <property name="javaws.cfg.jauthenticator" value="none" /> jws still opens its own dialog when acessing the JNLP file and the relevant JARs during the startup/download phase. of course, who else if not jws could handle that phase? my application might not even be downloaded at this point. so i guess setting my own Authenticator would not be a solution either (at least not if i want to secure my jnlp and my jars, too). quite the contrary, it would have to open another dialog... :-(
my current solution:*
for the moment i use jws' default Authenticatior which allows me to easily protect all my stuff on the server side (jnlp, jar, etc). i can live with the two login dialogs at the initial startup. and instead of querying the credentials from jws' default Authenticatior at runtime, i set two system properties for username and password in the (protected) jnlp-file, query them at runtime and hand it to vfs and httpclient. this prevents the 2nd (or 3rd) dialog but is definitely not a great solution. most of all i'm not happy with the fact that this somehow "destroys" the container-based security advantage of easily configuring authorized users via a separate mechanism e.g. tomcat-users.xml. now there has to be one master-password that has to be set in the jnlp-file! grrr!
a possible alternative:*
i'm not sure but would it be better to secure everything with form-based authentication on the website, and dynamically generate username and password into the jnlp-file? but what happens when the admin changes the password on the server and the user starts its application via desktop-link??? in case of basic authentication i think jws would popup the login dialog again. however, if i use the old username and password generated into the jnlp it won't work. i think the user then has to access the website again. this is not good at all! :-(
the only real solution:*
should i write a small application which can be downloaded by everybody and on startup queries the user's credentials, validates them with the help of our server, and uses the javax.jnlp-api to download the secured JARs of my real application? this seems so much overkill! does anybody have experiences with this approach? how difficult is it to implement the whole download/update stuff with javax.jnlp?
WHAT HAVE I MISSED???
AM I COMPLETELY WRONG???
WHAT IS THE EASIEST WAY???
AND WHAT IS THE BEST WAY???
thank you so much,
stephan

Answer 1

Not sure, whether I understood correctly, what you wanna do - but up to now I can't see any problem.
if you have a structure like this:
/ctxroot/
       launch.jnlp
       /app/
           *.jar
           *.whateveryou may use in your web.xml:
     <servlet>
          <servlet-name>JnlpDownloadServlet</servlet-name>
          <servlet-class>jnlp.sample.servlet.JnlpDownloadServlet</servlet-class>
     </servlet>
     <servlet-mapping>
          <servlet-name>JnlpDownloadServlet</servlet-name>
          <url-pattern>*.jnlp</url-pattern>
          <url-pattern>/app/*</url-pattern>
     </servlet-mapping>
     <security-constraint>
          <web-resource-collection>
               <web-resource-name>Application</web-resource-name>
               <url-pattern>/app/*</url-pattern>
               <http-method>GET</http-method>
               <http-method>POST</http-method>
          </web-resource-collection>
          <auth-constraint>
               <role-name>bla</role-name>
               <role-name>fahsel</role-name>
          </auth-constraint>
          <user-data-constraint>
               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
          </user-data-constraint>
     </security-constraint>
     <security-constraint>
          <web-resource-collection>
               <web-resource-name>Subscription</web-resource-name>
               <url-pattern>*.jnlp</url-pattern>
          </web-resource-collection>
          <user-data-constraint>
               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
          </user-data-constraint>
     </security-constraint>
     <login-config>
          <auth-method>BASIC</auth-method>
          <realm-name>whatever-realm</realm-name>
     </login-config>
     <security-role><role-name>bla</role-name></security-role>
     <security-role><role-name>fahsel</role-name></security-role>
...Than you may use the Service stuff like:
     BasicService bs = (BasicService)ServiceManager.lookup("javax.jnlp.BasicService");
     URL codeBase = bs.getCodeBase();
     URL pu = new URL(codeBase.toString() + "whatever.bla");
     HttpURLConnection res = (HttpURLConnection) pu.openConnection();
     res.setInstanceFollowRedirects(true);
     res.setRequestMethod("GET");
     res.setConnectTimeout(10 * 60 * 1000);
     res.connect();
     String enc = res.getContentType();
...Where is the problem? If you wanna intercept certain "calls" to an app resource, just use a filter, which decides, whether to answer the request directly by itself or to pass it to the JnlpDownloadServlet ...