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. 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 2. Try somehow to force usage of the BC implementation of javax.crypto.* instead of IBM's - this will prevent cross-classloader issues. 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. 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]
