Re: [WSS4J] Using wss4j from within a SecurityDomain

Jason,

Checked in and Thanks. Is it possible to submit a small test case, just so we don't break the
functionality.

thanks,
dims

--- Jason Essington <[email protected]> wrote:
> I am using wss4j from within an environment where a keystore and 
> truststore are already available programatically, but aren't 
> necessarily available to load from the filesystem.
> 
> My solution was to simply subclass some of the wss4j pieces to handle 
> this situation, but this also required adding some hooks so that the 
> private/package fields of these classes could be set.
> 
> First, in org.apache.ws.security.components.crypto.Merlin:
> 	I had to add a setKeyStore(KeyStore ks) method. This method could be 
> called from anywhere the load(InputStream is) method would be called. 
> It simply sets the keystore to the value supplied. This way a subclass 
> of Merlin could just take its instance of keystore and feed it to 
> setKeyStore().
> 
> Next, in org.apache.ws.axis.security.WSDoAllSender:
> 	I added a loadSignatureCrypto() and loadEncryptionCrypto() hook to 
> allow subclasses to instantiate their Crypto implementations however 
> they thought best. These hooks return a Crypto and are called from the 
> decode...Parameter() method like so:
> 		sigCrypto = loadSignatureCrypto();
> 	The bits from WSDoAllSender that instantiate the Crypto instances were 
> moved into these new protected methods.
> 
> Finally, in org.apache.ws.axis.security.WSDoAllReceiver:
> 	I added hooks similar to the ones in WSDoAllSender.  Since 
> WSDoAllReceiver doesn't have much to do with decryption/signature 
> parameters past loading the Crypto implementation for each, these hooks 
> basically consumed all the code from the decode...Parameter() methods.
> 
> The patched version of wss4j was tested in an environment where the 
> client side was basically Axis run from the command line, and the 
> server side was Axis (from within JBoss.net). Everything performed as 
> expected. And of course the patch doesn't cause any of the tests to 
> fail.
> 
> Hopefully these changes have some use past the environment I am working 
> in and will be applied to wss4j.
> 
> 

> ATTACHMENT part 2 application/octet-stream x-unix-mode=0644; name=cryptoHooks.patch
> 
> 
> Jason Essington
> jaessing-0ehoRKBSFavH/[email protected]


=====
Davanum Srinivas - http://webservices.apache.org/~dims/


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn