Hi all, I have also been having problems getting WSS4j to work with Websphere 6.0 on Solaris. From what I have found it is all caused by the way that IBM have set up the security providers. The problems I have been experiencing may be isolated to Websphere 6.0 on Solaris due to the JDK being used by Websphere.
By default Websphere sets up the following providers: security.provider.1=com.ibm.security.jgss.IBMJGSSProvider security.provider.2=sun.security.provider.Sun security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.jsse.IBMJSSEProvider security.provider.5=com.ibm.security.cert.IBMCertPath The problem occurs when I attempt to call the secure web service. Either I get java.lang.ExceptionInInitializerError with a root case of "Public key presented not for certificate signature" or you may see java.lang.NoClassDefFoundError within an empty message. As a temporary work around (until we have a more configurable Wss4j) I have changed the providers to be: security.provider.1=com.ibm.crypto.provider.IBMJCE security.provider.2=com.ibm.jsse.IBMJSSEProvider security.provider.3=com.ibm.jsse2.IBMJSSEProvider2 security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath This works but I do agree that in an ideal world we should not changing JCE provides. Chris. -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: 23 September 2006 12:13 To: Markus Backman Cc: Fred Dushin; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: [POSSIBLE SPAM] - Re: SV: AW: Bouncy castle +Websphere 6.0 + WSS4j 1.5 issue - Sending mail server found on list.dsbl.org For #1, As far as possible, the defaults should reflect current behavior... For #2, I'd think so. On 9/23/06, Markus Backman <[EMAIL PROTECTED]> wrote: > > > > Hi > > I agree with Fred that WSS4J is a library code and it shouldn't make any > assumptions on the environment WSS4J is run in. That includes not tampering > with the JCE provider list and be able to use any specified security > provider. > > As WSS4J is a general purpose library code that only has dependencies to > other general purpose library code it should not add any more dependencies > as necessary. With the work project I was a part of my initial plan was to > use WSS4J without AXIS and using Webspheres build in Web Service generator > and only attach the WSS4J jaxrpc handler to take care of the security before > the message reached the business logic. This wasn't possible due to the > Websphere Web Service servlet somehow changed the format of the message > before it reached the WSS4J handler. So I ended up using WSS4J together with > AXIS. But I appose that WSS4J is packaged together with WSS4J AXIS > extensions. If WSS4J should be a general purpose library code it should be > packaged as such, that is a jar file containing only the core and a AXIS > WSS4J jar file containing the extension for AXIS. > > But back to the getting WSS4J running on Websphere. As Fred states these two > changes should be needed: > > * Implement a property to disable/enable the dynamic changing of the JCE > provider list. A question here is if the property should be enable or > disabled by default? > * Implement so that if the JCE provider property is set this provider is > always used. Should such a property be obligatory? > > > I have test environments for Websphere 5.1, 5.0, 4.0 and in a near future > 6.0. And I can together with Fred implement and test these changing if we > can agree on the requirements for the change. > Best regards, > Markus > > > Fred Dushin wrote: > I think there are several principles we need to observer here, using the > assumption that the WSS4j toolkit is a piece of library code, and that it is > co-resident with other applications. > > First, we should in no circumstances be perturbing the list of JCE > providers in the toolkit. There is no guarantee that changing the global > state of the JCE will not screw up an application that already may have > dependencies on a certain JCE configuration, be it programmatic, or static > (in the JVM configuration). > > That's not to say, by the way, that applications that deploy the WSS4j > toolkit can't do this. If you want or need to do this in, say, > Axis-specific code, then be my guest. Just don't do it in general purpose > library code. > > Secondly, I have always found it useful to always parameterize calls to the > JCE with a provider, which may be configurable. I think this is echoing > Markus' suggestion, but I'd go a step further and require that the provider > name, itself, be configurable. (I suspect this is actually what Markus is > suggesting, but I thought I'd clarify this, just the same). This way, the > WSS4j toolkit can no explicit or implicit dependencies on Bouncycastle, > Juice, or <insert your favorite JCE provider here>. > > I would be happy to work with Markus on addressing these changes in the > WSS4j core. > > -Fred > > [EMAIL PROTECTED] wrote: > > Hi > > I can only agree as I also have tried to run WSS4J with Websphere with IBM > JDK. The WSS4J secured web service that is used by the company I work for is > in production running on Websphere 5.1. But as I completed this a while back > the solution was based on WSS4J 1.1 and not 1.5. With 1.1 I hade to make > modification on the WSS4J source to always ask for the provider BC to be > sure that BouncyCastle is picked. And then there was no trouble to have > BouncyCastle last in the provider list. > > But as WSS4J 1.5 automaticly places BouncyCastle at number 2 in the provider > list when WSS4J is first loaded IBM JDK while encounter the problem > descriped below. There are two ways around this, the first is to make the > placement of the BouncyCastle provider changeable with some property, the > second is to always ask for the BC provider if some property is set. As IBM > JDK has these fault in their JCE handling a combined solution of 1 and 2 is > proberly nessessary for making WSS4J work on IBM JDK. With these properties > set WSS4J should work on IBM JDK without any source changes. But of course > these solution must first be implemented. > > Regards, > Markus > > ________________________________ > Från: Dittmann, Werner [mailto:[EMAIL PROTECTED] > Skickat: den 21 september 2006 08:17 > Till: Fred Dushin > Kopia: vivek srinivasan; [email protected] > Ämne: AW: AW: Bouncy castle +Websphere 6.0 + WSS4j 1.5 issue > > > Well, the ordering of the JCE providers is an ongoing topic anyhow :-) . > > - The very first entry in the list is somehow reserved by SUN to be able to > do JCE verification (JAR verification). Thus we can't use that. > - Then we decided to register BC on the second place because > sometimes with some JDKs (also IBM's) we got an error when we need > the strong RSA algorithm. > > Let me explain: > > some JCE (name it JCE-1) includes a RSA algorithm and this RSA supports > keys up to 512 bits > > another JCE (name it JCE-2) includes a RSA algorithm and this RSA supports > keys up to 2048 bits > > JCE-1 is on the JCE provider list at position 2, JCE-2 at position 3. Now > you > do a lookup for the RSA algorithm, you will get the JCE-1 RSA class. But > what happens > if you need RSA keys with more than 521 bits? No way out because there is no > way to define the "key strength" during lookup. This happend several times > in > the past - WSS4J requires strong keys as defined by OASIS. > > Some JCE provider don't support bigger keys - that was the main reason to > have > BC at position 2. Except for IBM's JDK this seems no problem so far. The Sun > JDK, > the BEA JRockit and probably others work well with this. > > As far as WSS4J is concerned, IBM's JDK had the most problems with respect > to JCE handling. > > Regards, > Werner > > > ________________________________ > Von: Fred Dushin [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 20. September 2006 20:58 > An: Dittmann, Werner > Cc: vivek srinivasan; [email protected] > Betreff: Re: AW: Bouncy castle +Websphere 6.0 + WSS4j 1.5 issue > > Actually, I wonder if the following issue is related. > > The WSSConfig class insists on inserting the Bouncycastle JCE provider > "first" (or second...) in the list of JCE providers, if it can be found on > the classpath. > > The IBM JDK does not seem terribly appreciative of this fact, as the > following test case illustrates. For me, on AIX, using IBM's 1.4.02 JDK, > the following code fails with "java.security.KeyStoreException: jks not > found". If I add the Bouncycastle provider to the end of the list of > providers, I don't get the error. > public class Test { > > public static void > main( > String[] argv > ) { > try { > > java.security.Security.insertProviderAt( > (java.security.Provider) > Class.forName( > "org.bouncycastle.jce.provider.BouncyCastleProvider" > ).newInstance(), > 2 > ); > final java.security.KeyStore keystore = > java.security.KeyStore.getInstance( > "jks" > ); > java.io.FileInputStream fis = > new java.io.FileInputStream( > "alice.jks" > ); > keystore.load(fis, "password".toCharArray()); > > } catch (Exception e) { > e.printStackTrace(); > } > } > } > > Truss on AIX shows some intersting behavior. It looks like the JVM can't > locate > org/bouncycastle/jce/provider/JDKMessageDigest$SHA1.class, > but it's a bit hard to decipher. > > In any event, I think they fact that the WSS4j toolkit is statically > injecting a provider into the JVM at runtime is pretty wrong, especially in > library code that has to co-exist peacefully in an otherwise potentially > hostile environment... > > I'll file a bug, and consider what can be done for a patch. > > -Fred > > Dittmann, Werner wrote: > IMHO it's quite simple: BC does not support the BKS keystore > type. Also you may define which provider to use and the keystore > type in the security property file. > > Regards, > Werner > > > > > -----Ursprüngliche Nachricht----- > Von: vivek srinivasan [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 04:40 > An: [EMAIL PROTECTED]; [email protected] > Betreff: RE: Bouncy castle +Websphere 6.0 + WSS4j 1.5 issue > > Here isthestack trace > [junit] java.security.KeyStoreException: BKS not found > [junit] at > java.security.KeyStore.getInstance(KeyStore.java:233) > [junit] at > org.apache.ws.axis.security.WSDoAllSender.invoke(WSDoAllSender > .java:56) > [junit] at > org.apache.axis.strategies.InvocationStrategy.visit(Invocation > Strategy.java:32) > [junit] at > org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) > [junit] at > org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) > [junit] at > org.apache.axis.client.AxisClient.invoke(AxisClient.java:127) > [junit] at > org.apache.axis.client.Call.invokeEngine(Call.java:2784) > [junit] at > org.apache.axis.client.Call.invoke(Call.java:2767) > [junit] at > org.apache.axis.client.Call.invoke(Call.java:2443) > [junit] at > org.apache.axis.client.Call.invoke(Call.java:2366) > [junit] at > org.apache.axis.client.Call.invoke(Call.java:1812) > [junit] at > test.com.ams.coretest.serverdependent.webservices.WSSecurityTe > stServiceSoapBindin > gStub.testX509NoFault(WSSecurityTestServiceSoapBindingStub.java:637) > [junit] at > test.com.ams.coretest.serverdependent.webservices.WSSecurity_S > erviceTestCase.test > X509NoFault(WSSecurity_ServiceTestCase.java:65) > [junit] at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > [junit] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.java:85) > [junit] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.java:58) > [junit] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessorImpl.java > :60) > [junit] at java.lang.reflect.Method.invoke(Method.java:391) > [junit] at > junit.framework.TestCase.runTest(TestCase.java:166) > [junit] at > junit.framework.TestCase.runBare(TestCase.java:140) > [junit] at > junit.framework.TestResult$1.protect(TestResult.java:106) > [junit] at > junit.framework.TestResult.runProtected(TestResult.java:124) > [junit] at junit.framework.TestResult.run(TestResult.java:109) > [junit] at junit.framework.TestCase.run(TestCase.java:131) > [junit] at > junit.framework.TestSuite.runTest(TestSuite.java:173) > [junit] at junit.framework.TestSuite.run(TestSuite.java:168) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.r > un(JUnitTestRunner. > java:297) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.l > aunch(JUnitTestRunn > er.java:672) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.m > ain(JUnitTestRunner > .java:567) > [junit] java.security.KeyStoreException: BKS not found > [junit] at > java.security.KeyStore.getInstance(KeyStore.java:233) > [junit] at > com.ams.core.security2.csf.webservices.WSS4JCSFCryptoImpl.<ini > t>(WSS4JCSFCryptoIm > pl.java:40) > > > > > From: "vivek srinivasan" <[EMAIL PROTECTED]> > To: [email protected] > Subject: Bouncy castle +Websphere 6.0 + WSS4j 1.5 issue > > Date: Tue, 19 Sep > > > 2006 02:33:45 +0000 > > Hi, > > I have all the types of authentication(SAML,username token > > etc..) working > > > in Weblogic using WSS4J . But when i try to use the IBM JVM, > > it does not > > > recognize the BC provider and type BKS.The call to > KeyStore.getInstance("BKS","BC") throws an exception that > > the Type BKS is > > > unknown.Is WSS4j doing anything "special"? ANd does WSS4J run with > websphere 6.0? > Here is the java.security file > security.provider.1=com.ibm.crypto.provider.IBMJCE > security.provider.2=com.ibm.jsse.IBMJSSEProvider > security.provider.3=com.ibm.jsse2.IBMJSSEProvider2 > security.provider.4=com.ibm.security.jgss.IBMJGSSProvider > security.provider.5=com.ibm.security.cert.IBMCertPath > #security.provider.6=com.ibm.crypto.pkcs11.provider.IBMPKCS11 > security.provider.6=org.bouncycastle.jce.provider.BouncyCastl > > eProvider > > > security.provider.7=com.ibm.crypto.pkcs11.provider.IBMPKCS11 > security.provider.8=com.ams.csf.provider.CSFProvider > > I have the BC provider jar in jre/lib/ext. > > _________________________________________________________________ > Be seen and heard with Windows Live Messenger and Microsoft LifeCams > http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/? > > href=http://www.microsoft.com/hardware/digitalcommunication/de > fault.mspx?locale=en-us&source=hmtagline > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > _________________________________________________________________ > Add fun gadgets and colorful themes to express yourself on > Windows Live > Spaces > http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?h > ref=http://www.get.live.com/spaces/features > > > --------------------------------------------------------------------- > 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] > > > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- 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]
