Ohhhh, I think I get what you are suggesting now. I can simply implement my own custom Crypto class and specify that instead of org.apache.ws.security.components.crypto.Merlin. Then I can source the key/cert data from any where I choose.
Perfect and much cleaner too. Disregard my previous ramblings :). Richard Wareing Reimer Technology Group > -----Original Message----- > From: Richard Wareing [mailto:[EMAIL PROTECTED] > Sent: 2005 September 27 11:42 AM > To: 'Dittmann, Werner'; 'Apache WSS4J-Dev Mailing List' > Subject: RE: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > Hi, > > Let me try to elaborate. First off let me preface this by stating I'm > fairly new to WSS4J (i.e. been using it for only 3 weeks), however I've > managed to make most combinations of Signature/Encryption to work (in > both directions). That said, I'm not intricately familiar with the > source base as many of you are probably, and thus can't speak for the > feasibility of any of what I'm proposing so bear with me :). > > One thing that I think many would find useful is the ability to use a > CallBack class to retrieve the key associated with a key name in > verifying or signing messages. i.e. instead of going to a keystore file > to retrieve the key, you can retrieve the key from an alternate source > (e.g. database table). Retrieving keys in this manner would allow a lot > of flexibility for key management I think. > > Now maybe I'm misinterpreting the docs regarding the > ENC_CALLBACK_CLASS/ENC_CALLBACK_REF feature, but I understood these > features to do something along those lines (e.g. allow you to retrieve > the encryption/decryption keys from a place of your choosing vs. the > keystore file). > > What do you guys think? Ultimately my goal would be to have a method of > managing the keys on the web service end with a nice web interface: i.e. > customers submitting their public signature/encryption keys on the fly, > or conversely downloading the servers public signature/encryption key on > the fly for bi-directional web services security. > > I'm not sure how I can accomplish this goal with the traditional > keystore mechanism. Any suggestions & comments are of course welcome. > > Regards, > > Richard Wareing > Reimer Technology Group > > > > > -----Original Message----- > > From: Dittmann, Werner [mailto:[EMAIL PROTECTED] > > Sent: 2005 September 27 1:31 AM > > To: Richard Wareing; Apache WSS4J-Dev Mailing List > > Subject: AW: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > > Richard, > > > > I'm not sure if I understand your proposal correctly. > > Couldn't that be done by extending/implementing another > > class that implements the Crypto interface? Classes > > that implement this interface a Merlin and BouncyCastle > > in the **/components/crypto package. > > > > Regads, > > Werner > > > > > -----Ursprüngliche Nachricht----- > > > Von: Richard Wareing [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 27. September 2005 00:01 > > > An: Apache WSS4J-Dev Mailing List > > > Betreff: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature? > > > > > > > > > Are there any plans on implementing such a feature? It would be > handy > > > to have in order to lookup a remote WS client's public "signature > key" > > > instead of a grabbing it from a key store file. This would be > similar > > > to what apparently can be done with encryption via the > > > ENC_CALLBACK_REF/ENC_CALLBACK_CLASS (see WSHandlerConstants API > docs). > > > > > > Regards, > > > > > > Richard Wareing > > > Reimer Technology Group > > > > > > > > > --- > > > [This E-mail scanned for viruses by Declude Virus] > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > --- > > [This E-mail scanned for viruses by Declude Virus] > > > --- > [This E-mail scanned for viruses by Declude Virus] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --- > [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
