Sean McGarvey

I have been trying desparately for weeks to get SSL working with an existing application that uses XmlRpc between a servlet running on a web server and an applet running through a web browser.

I found the following code online:

import java.util.*;
import java.net.*;
import com.sun.net.ssl.*;
import java.security.cert.X509Certificate;
import java.security.Security;
import javax.net.ssl.SSLSocketFactory;
//import helma.xmlrpc.XmlRpcClient;
import marquee.xmlrpc.*;

/** * SecureXmlRpcClient provides an XML-RPC client that can operate over SSL and that can negotiate
* basic authorization. It is simply a wrapper of Security and URL configuration around an instance
* of the XML-RPC client implementation provided by the marquee package */

public class SecureXmlRpcClient{
private String username;
private String password;
private String urlstring;
private XmlRpcClient client;

/** * Requires the url of the XML-RPC service, the user and password for authentication */
public SecureXmlRpcClient(String urlstring, String username,String password) throws Exception{
this.username = username;
this.password = password;
this.urlstring = urlstring;
//Configuration work to provide SSL support
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");

//Currently server cert is not signed by a CA //so work around by using own TrustManager
X509TrustManager tm = new WorkAroundX509TrustManager();
KeyManager []km = null;
TrustManager []tma = {tm};
SSLContext sc = SSLContext.getInstance("ssl");
sc.init(km,tma,new java.security.SecureRandom());
SSLSocketFactory sf1 = sc.getSocketFactory();
HttpsURLConnection.setDefaultSSLSocketFactory(sf1);

//end workaround for non-CA signed server cert
//Configuration work to allow negotation of basic authroisation

NetPermission np = new NetPermission("setDefaultAuthenticator");
BasicAuthenticator ba = new BasicAuthenticator(username, password);
java.net.Authenticator.setDefault(ba);
URLConnection.setDefaultAllowUserInteraction(true);
//this.client = new XmlRpcClient(urlstring);
this.client = new XmlRpcClient("server",443,"/app/XmlRpcManager");
}

/** * Execute the required XML-RPC procedure with the required parameters (traffic between the * client and server will be encrypted if the url was s secure one) */

// public Object execute (String s, Vector v)throws Exception{
// return client.execute(s,v);
// }
public Object invoke (String s, Object v[])throws Exception{
return client.invoke(s,v);
}

/** * Inner class to provide a permisive TrustManager for non CA signed server certificates) */
private class WorkAroundX509TrustManager implements X509TrustManager {
public boolean isClientTrusted(X509Certificate[] chain){
return true;
}
public boolean isServerTrusted(X509Certificate[] chain){
return true;
}
public X509Certificate[] getAcceptedIssuers(){
return null;
}
}

/** * Inner class to provide an implemtation of Authenticator */
private class BasicAuthenticator extends Authenticator {
private String username = "";
private String password = "";

public BasicAuthenticator(String username, String password){
this.username = username;
this.password = password;
}
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(this.username, this.password.toCharArray());
}
}
}

The problem seems to be that the client cannot execute the addProvider call:

Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

and the following error is raised when it tries to:

java.security.AccessControlException: access denied (java.security.SecurityPermission insertProvider.SunJSSE)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkSecurityAccess(Unknown Source)
at sun.plugin.security.ActivatorSecurityManager.checkSecurityAccess(Unknown Source)
at java.security.Security.check(Unknown Source)
at java.security.Security.insertProviderAt(Unknown Source)
at java.security.Security.addProvider(Unknown Source)

If anyone has any ideas, I would GREATLY APPRECIATE it. Some sample source code of a working example where the client runs in a web browser would be fantastic.

Thank you,
Sean

Also, I just noticed that when I try to access it locally (from the server) using the server name instead of localhost, IE reports that the cookie is blocked and the jsessionid shows up in the url. The servlet session is lost.

Any ideas would be greatly appreciated.

I tried checking the Allow All Session Cookies check box and I also tried setting it to Allow All Cookies (the lowest security level) and IE still tells me that it is blocking a cookie. When I access this same application from the same IE (on the same pc) through a difference server, the cookie isn't blocked, the jsessionid doesn't show up in the url and everything works properly. When I say that I am running the same application, I mean that the app.war files are identical.

If I log onto the application on the server that isn't working properly using localhost in the url, the application functions properly. Why would it work when I use access it locally using localhost and not when I access it through our LAN using the server name?

I have a web application that uses Java Applets and Servlets. The applets are actually embedded within a servlet generated jsp. I have been hosting this application with JRun using Apache and IIS, but am trying to move it to JBoss.

The problem that I am having is with reproducing an Apache/Tomcat/Jboss environment that I have found (actually for another application) which works perfectly for my application.

In the environment that I have setup, when I log on to my application (from a jsp logon page), my applet builder servlet seems to imediately loose the session. What I am observing is that the url displayed has the jsessionid added to it (which doesn't happen in my working environment) like this:

http://samcgarvey/myapp/html/index.jsp;jsessionid=6663CB32CC64EF58EB7BE71DAAE366EB.samcgarvey

Also, the internet explorer privacy report shows that IE blocked a cookie, even though I am positive that IE is setup to allow all cookies.

One difference between the two server environments (that I am awair of) is that the working environment uses JavaService to run JBoss and the other is just running JBoss using the run.bat command. I am having some difficulty setting up the JavaService and am more concerned with the jsession problem at this point. Could this be my problem?

I am running out of ideas here. Any suggestions would be greatly appreciated.

Thank you in advance,
Sean

I have a web application that uses Java Applets and Servlets. The applets are actually embedded within a servlet generated jsp. I have been hosting this application with JRun using Apache and IIS, but am trying to move it to JBoss.

The problem that I am having is with reproducing an Apache/Tomcat/Jboss environment that I have found (actually for another application) which works perfectly for my application.

In the environment that I have setup, when I log on to my application (from a jsp logon page), my applet builder servlet seems to imediately loose the session. What I am observing is that the url displayed has the jsessionid added to it (which doesn't happen in my working environment) like this:

http://samcgarvey/myapp/html/index.jsp;jsessionid=6663CB32CC64EF58EB7BE71DAAE366EB.samcgarvey

Also, the internet explorer privacy report shows that IE blocked a cookie, even though I am positive that IE is setup to allow all cookies.

One difference between the two server environments (that I am awair of) is that the working environment uses JavaService to run JBoss and the other is just running JBoss using the run.bat command. I am having some difficulty setting up the JavaService and am more concerned with the jsession problem at this point. Could this be my problem?

I am running out of ideas here. Any suggestions would be greatly appreciated.

Thank you in advance,
Sean

Ben,

Thank you for the suggestion. I believe that I am already doing exactly what you suggested though.

I did notice that when I try to access the web application running the client through IE directly on the web server, everything works fine. However, when I try to access from another host, I am getting an IE privacy report stating that the cookie was blocked. Also, I notice that the parameter "jsessionid=###" is in the url query. I have tried this from different hosts and am sure that the privacy settings on each host are setup to allow all cookies.

I think that my problem must have something to do with how I have setup Apache and JBoss on my web server. Are you aware of any server settings that I might need to modify?

Thank you,
Sean

I have a web application that uses applets and servlets. When I use getAppletContext().showDocument() to send a url to my servlet, the servlet cannot retireve the session information using session.getAttribute(). In fact, request.getSession(false) returns null.

This seems to be working properly on IIS, but when I try to configure Apache, it fails unless the client is running on the server.

Any ideas would be greatly appreciated.

Thank you,
Sean

I am working on a problem similar to this. When I use getAppletContext().showDocument() to invoke my servlet to produce output to be displaying in a web browser, everything works great.

The problem is that the servlet does not receive the session info from the applet. In fact, request.getSession(false) returns null.

Any suggestions? Is there an Apache setting that I need to configure?

Thanks,
Sean

I have a web application that uses applets and servlets. When I use getAppletContext().showDocument() to send a url to my servlet, the servlet cannot retireve the session information using session.getAttribute(). In fact, request.getSession(false) returns null.

This seems to be working properly on IIS, but when I try to configure Apache, it fails unless the client is running on the server.

Any ideas would be greatly appreciated.

Thank you,
Sean