Hi all, I finally got my code working.
To recap, I was having trouble using secret key encryption in Rampart. More specifically, the trouble appeared to be related to the JCE cryptography library when using IBM's Java and WebSphere. I was getting a ClassCastException and some of you were helpful to suggest that it was a class loader problem. I did write a custom classloader and used it to force the loading of the BouncyCastle classes, but that didn't seem to help - I still got the same error. So I changed org.apache.security.encryption.XmlCipher such that now it uses the BC lightweight API instead of going through JCE. I understand why this is not desirable as it creates a dependancy from xml-security to BC. But for me, it's a good enough fix for now. I also changed a class in wss4j to not throw an exception if it can't find a keystore file, as I'm providing the secret key in a call back class and I'm not using certificates. So now I've got it working the way I want it. I don't need to install certificate files on the client or server, and I don't have any JCE problems, so when it's time to deploy and I have to send my .ear file to the nasty department across town that will host our app, I'll be more confident that there won't be any issues. It has been a lot of fun getting to know all of this code. Everything I've seen looks well written. cheers, Michael Davis Ottawa > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 1:53 PM > To: [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [dev-crypto] Bug in Cipher class? > > > Thanks once again! > > > So to sum it up I see 3 ways to try to fix this: > > 1. Follow david's advice and try to have BC loaded > alongside with the > > IBM JCE. The WSS4J > > will see its already loaded and not try to reaload it > > I tried that. It seems to break other websphere stuff. > > > 2. Try somehow to force usage of the BC implementation of > > javax.crypto.* > > instead of IBM's - > > this will prevent cross-classloader issues. > > I'm trying to figure out a way to do that. > > > 3. Overload your thread classloader - and implement > protection of some > > classes via the > > loadClass(String) method and try to manually load the BC JCE > > in the JCE > > classloader. > > I'll try that if I can't do #2. > > cheers, > md > > > > -----Original Message----- > > From: George Stanchev [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 18, 2007 1:44 PM > > To: Davis, Michael; [EMAIL PROTECTED] > > Cc: [email protected]; [EMAIL PROTECTED] > > Subject: RE: [dev-crypto] Bug in Cipher class? > > > > > > > > Michael, > > > > Unfortunately (or at least that's how I understand it) > > in your case you don't have control over the classloader that > > is running > > WSS4J to > > do delegate the loading to the system classloader. In my > case, I have > > implemented > > my own isolating classloader and I haveoverloaded the > > loadClass() method > > to "protect" > > some classes - if they are on the protection list, their loading is > > delegated to the parent > > classloader. > > > > I am not familiar with > > websphere but does it load the IBM JCE in a separate, higher > > classloader > > then your > > Thread.getCurrentThread().getContextClassloader()? And why is your > > javax.crypto.Cipher > > picked up from the websphere classloader instead of the > BC's provided > > javax.crypto.Cipher (they do provide an implementation withing their > > JCE)? > > If you can make your app to load javax.crypto.Cipher from the > > BC JCE in > > the > > application CL, I think woould fix your problem. > > > > Best Regards, > > George > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 18, 2007 10:53 AM > > To: [EMAIL PROTECTED] > > Cc: [email protected]; [EMAIL PROTECTED] > > Subject: RE: [dev-crypto] Bug in Cipher class? > > > > Thanks very much, George. > > > > First I'll try your solution to see if I can get it to work. If I > > understand correctly, I need to do this: > > > > ClassLoader cl = java.security.Security.class.getClassLoader(); > > Class bcClass = cl.loadClass( > > "org.bouncycastle.jce.provider.BouncyCastleProvider" ); > > > > But I'm not sure how to do the next step: > > "and then restricting the javax.crypto.* and > > org.bouncycastle.* packages > > to be always loaded from the parent classloader." > > > > I also tried doing: > > > > Cipher cipher = Cipher.getInstance( algo, new > > BouncyCastleProvider() ); > > > > but it didn't work for the reasons you explain below. > > > > cheers, > > md > > > > > > > -----Original Message----- > > > From: George Stanchev [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, July 18, 2007 12:40 PM > > > To: [EMAIL PROTECTED] > > > Cc: [email protected] > > > Subject: RE: [dev-crypto] Bug in Cipher class? > > > > > > > > > I ran into similar problem with the BC provider supplied > with axis2 > > > since my app is running in an isolating classloader. For > me, I was > > > able to fix it by loading the BC JCE provider in the > > > java.security.Security.class.getClassLoader() > > > classloader and then restricting the javax.crypto.* and > > > org.bouncycastle.* packages > > > to be always loaded from the parent classloader. Of course if the > > > security restrictions forbid me of getting a hold of the JCE > > > classloader I am screwed and my users need to add the jars > > manually to > > > > > the jre/lib/ext directory as David indicated below. > > > > > > If WSS4J is relying on BC, then it should assure the proper > > > classloader picks up the package. > > > > > > An alternative solution would be to not go via the > > > java.security.Security JCE registry and use the JCE > > provider directly > > > via XXX.getInstance(String transformation, Provider prov) > > calls. But > > > for some reason (and here the WSS4J developers can chime > in) WSS4J > > > relies on the Java 1.3 JCE interfaces which lack those > methods and > > > need to go via the security registry. > > > > > > WSS4J devs, is there a reason to stay with the 1.3 BC > > provider or you > > > can switch to the BC's JDK 1.4 provider? > > > > > > Michael, I think its worth submitting a JIRA against that issue. > > > > > > Best Regards, > > > George > > > > > > -----Original Message----- > > > From: David Hook [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, July 17, 2007 5:00 PM > > > To: [EMAIL PROTECTED] > > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > > [email protected] > > > Subject: RE: [dev-crypto] Bug in Cipher class? > > > > > > > > > Try putting the provider jar in jre/lib/ext and add BC to the > > > java.security file as well. > > > > > > Regards, > > > > > > David > > > > > > On Tue, 2007-07-17 at 11:03 -0400, > [EMAIL PROTECTED] > > > wrote: > > > > Thanks very much for your reply, David. Now I have > > something to work > > > with. > > > > > > > > I tried removing the BouncyCastle jar from my project, > > but it looks > > > > like wss4j requires it. When I remove it, I get an error > > > saying that > > > > Cipher can't find a provider supporting the algorithm. I > > > tried it with > > > > > > > the algorithms defined in wss4j, namely > > > > > > > > AES/CBC/ISO10126Padding and DESede/CBC/ISO10126Padding. > > > > > > > > this happens both on Sun's java with providers SUN, SunJSSE, > > > SunRsaSign, SunJCE and SunJGSS, and on IBM's java with providers > > > IBMJCE, IBMJSSE, IBMJGSSProvider, IBMCertPath and > IBMPKCS11. (I get > > > those by printing out what's returned by > Security.getProviders() ). > > > > > > > > I tried setting the algorithm to "AES" to see if that > > > works, but that > > > causes a null pointer exception in wss4j, so I figure I > need to use > > > the ones that are defined in wss4j. > > > > > > > > So I'm stuck. With IBM's java, I get the class loader issue if I > > > supply the BouncyCastle jar, and I get an UnsupportedAlgorithm > > > exception if I don't. > > > > > > > > Any hints would be very gratefully appreciated! > > > > > > > > cheers, > > > > Michael Davis > > > > > > > > > > > > > -----Original Message----- > > > > > From: David Hook [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, July 16, 2007 8:35 PM > > > > > To: Davis, Michael > > > > > Cc: [EMAIL PROTECTED] > > > > > Subject: Re: [dev-crypto] Bug in Cipher class? > > > > > > > > > > > > > > > > > > > > It's a class loader issue - ciphers need to be loaded by > > > the system > > > > > class loader as the JCE is loaded by it. If the > > provider jar gets > > > > > loaded by another untrusted class loader the > > > getInstance() call on > > > > > Cipher will fail with either ClassNotFoundException > if no other > > > > > class loader can return the class, or > ClassCastException if the > > > > > class is returned by a class loader but isn't properly > > annotated. > > > > > > > > > > You need to make sure the same class loader is picking up the > > > > > provider jars as is picking up the JCE classes. > > > > > > > > > > Regards, > > > > > > > > > > David > > > > > On Mon, 2007-07-16 at 15:08 -0400, > > > [EMAIL PROTECTED] > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I've asked this question on the Apache xml security mailing > > > > > list, but I got no answer. I figure you folks must be > > experts on > > > > > this stuff, so... > > > > > > > > > > > > I'm developing a web service using Axis2. I'm using its > > > > > WS-Security framework to encrypt the xml messages. This > > framework > > > > > ultimately uses the Apache XML Security library, which > > > has this line > > > > > > > > of code: > > > > > > > > > > > > instance._contextCipher = Cipher.getInstance(jceAlgorithm); > > > > > > > > > > > > This works fine using the Sun jdk1.4, which uses Sun's > > > > > jce.jar and sunjce_provider.jar. It also works fine using the > > > > > BouncyCastle classes - Sun's Cipher class finds and > returns the > > > > > appropriate BC class. > > > > > > > > > > > > However, when I try to run the app on WebSphere 5.1, I get > > > > > this error: > > > > > > > > > > > > java.lang.ClassCastException: > > > com.ibm.crypto.provider.AESCipher at > > > > > > > > > javax.crypto.Cipher.getInstance(Unknown Source) > > > > > > > > > > > > This is getting thrown by IBM's javax.crypto.Cipher class > > > > > in ibmjcefw.jar. > > > > > > > > > > > > This happens even if I manipuate the providers to load the > > > > > BC classes first - in that case the class causing the > > > > > ClassCastException is > > > > > org.bouncycastle.jce.provider.JCEBlockCipher$AES. > > > > > > > > > > > > Have any of you ever seen this problem before? > > > > > > > > > > > > Many thanks, > > > > > > Michael Davis > > > > > > Ottawa > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************************************** > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to > > whom they > > > are addressed. Any unauthorized review, use, disclosure or > > > distribution is prohibited. If you are not the intended > recipient, > > > please contact the sender by reply e-mail and destroy all > copies of > > > the original message. > > > > > > ********************************************************************** > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
