Well, you may be right with regard to the statement "not changing JCE providers". What makes me wonder though is the fact that there are for more problems with IBM's JCE providers than we see with other JCE providers. AFAIK we don't get as much problem reports on Sun, BC or possible other providers.
IMHO there should be no difference at which position a JCE provider is in the list of providers. The _only_ reasons to put a JCE provider on a higher position could be: trust into the implementation and performance. Otherwise all crypto providers should behave exactly the same - at least this is my perception of a "perfect" JCE world. Sun already broke this when it required a specific provider at position 1 of the list to perform JAR validation. You have to be free to position your provider at any position you like. Among the reasons stated above there is also another important reason that is based in the design of the JCE interfaces: JCE is missing some parameters and attributes when it comes to initialization and selection of algorihms and providers, e.g. if you your program requires a 2048 bit RSA key and the JCE provider that implements this is on a lower position than one that only implements 1024 bit keys then your program is lost - except that you program knows which provider to use and your program has to name that provider. The most usual way to solve a problem is: use the best, most functional provider you get and tell you program to use it. Regarding the problem you like to solve here: I'm not sure if it helps to make WSS4J fully configurable with respect to JCE providers - however such a "full configuration option" looks like. As long as JCE providers behave in a way the IBM JCE providers do you will have this sort of problems. AFAIK most users of WSS4J didn't have a real problem with the inclusion of BC into the list. Still I believe the BC provider solved much more problems than it creates because it provides a full set of JCE functions usually not found in e.g. Sun's provider. Without the BC provider for example we wouldn't have a working WSS4J because the Sun provider, at that time, didn't even support all the algorithms that the WSS standard (based on the W3C standards) required. Maybe IBM shall adhere to the standards? Another question: is it really "just a temporary solution" to order the providers in the list in a way that all works and is OK? This is what the list and the JEC configuration is all about, isn't it? Shall we introduce yet another way to configure JCE providers for one library which may overlay/overwrite/disturb/interfere with the standard way to do it? Just some thoughts and my 2 € cents. :-) Regards, Werner Chris Harris wrote: > 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] >> >> >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
