Hello David, Dan Thanks for your advice. With the suggestion of Jarek, I started a simple webservice and client with ws-security support (with CXF first). When this will run with the ws-security support then we can start integrating the "right jars" into geronimo (into the cxf plugin). Further, once we have all the jars integrated in geronimo we can try using a geronimo client and connect to the standalone cxf service with ws-security.
Many Thanks for your support. Best Regards, Rahul On Tue, May 12, 2009 at 2:51 AM, Daniel Kulp <[email protected]> wrote: > On Mon May 11 2009 7:16:46 pm David Jencks wrote: > > On May 11, 2009, at 3:24 PM, rahul.soa wrote: > > > Hello everyone, > > > > > > As you know I am working on the support of ws-security module, so I > > > did some research about integrating the modules in Apache Geronimo > > > for the same. > > > > > > For the integrating/enabling WS-Security support, I think we need to > > > have the following jars and modules in Geronimo: > > > > > > Apache CXF: > > > > > > For WS-Security support we need to have following jar files from the > > > CXF: > > > > > > - bcprov-jdk15.jar > > > > Previously when we used some bouncy castle classes the jar included > > some classes that may well have infringed some us patents. I think I > > saw somewhere that bouncy castle had finally released a jar without > > thses classes. We should verify that this jar does not contain these > > classes. Also, we have copies of a bunch of the bc classes we need > > for other purposes in the geronimo-crypto module, so we should check > > that we don't already have the needed classes. > > Version 140 and later in maven have the patent covered algorithms removed. > Not an issue anymore. > > > > > > - xalan.jar > > > > really? I'd like to know why the xml transform support in the jdk is > > not sufficient. > > xmlsec uses some of the internal xalan classes. I could never get a good > reason as to why. > > > > - serializer.jar > > This goes with Xalan. > > > > > - wss4j.jar > > > - xmlsec.jar > > Note: all of those jars will be required for Axis2 as well. > > > > > Apache Axis2 > > > > > > 1. We need to integrate "Rampart*" module of axis2, > > > > > > 2. for step 1, need to download the Java Cryptography Extension > > > (JCE) Unlimited Strength Jurisdiction Policy Files corresponding to > > > JDK version and extract the jar files local_policy.jar and > > > US_export_policy.jar to $JAVA_HOME/jre/lib/security > > > > These are not something we can include, right? they'd have to be > > installed by the end user? > > Correct. However, for unit tests and such, we can PROBABLY use less > secure > algorithms. I have someone looking into the same issue for the CXF test > cases. We don't want to make every developer have to install the strong > crypto libraries. Basically, if the user needs the strong crypto stuff, > they > WILL need to download and install the strong crypto libs from Sun. > > Dan > > > > 3. for step 1, need to download bouncycastle according to java > > > version separately > > > > > > *Rampart is the security module of Axis2 > > > > > > > > > Please let me know if I am missing something and please also guide > > > me how can I get them in Geronimo. > > > > That depends partly on the classloader relationships needed between > > the main cxf/axis2 jars and these new ones. If appropriate cxf/axis2 > > jars and these jars can be in a classloader that is a child of the cxf/ > > axis2 "main" plugin classloaders, you should probably make cxf-wss and > > axis2-wss plugins with all the security related jars as dependencies. > > If this doesn't work and the classes need to be in the main cxf/axis2 > > plugin classloader then you probably need to just add these as > > dependencies. > > > > thanks > > david jencks > > > > > Thanks in advance. > > > > > > Regards, > > > Rahul > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog >
