Re: SIG_CALLBACK_REF/SIG_CALLBACK_CLASS feature?

Richard,

that's what I meant. Of course, the current implementation
uses feture of the keystore, e.g. looking up aliases, iterating
over aliases and so on.

But there are also some helpful method that just handle certificate
management, decoding, encoding, etc. Maybe you can subclass Merlin
and start with that.

Regards,
Werner

Richard Wareing wrote:
> 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:wareing-y0/d7ZP22M8@xxxxxxxxxxxxxxxx]
>>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:werner.dittmann-kv7WeFo6aLtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx]
>>>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:wareing-y0/d7ZP22M8@xxxxxxxxxxxxxxxx]
>>>>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: 
>>>>wss4j-dev-unsubscribe-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>>>For additional commands, e-mail: 
>>>>wss4j-dev-help-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>>>
>>>>
>>>
>>>
> ---------------------------------------------------------------------
> 
>>>To unsubscribe, e-mail: 
>>>wss4j-dev-unsubscribe-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>>For additional commands, e-mail: 
>>>wss4j-dev-help-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>>
>>>---
>>>[This E-mail scanned for viruses by Declude Virus]
>>
>>
>>---
>>[This E-mail scanned for viruses by Declude Virus]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: 
>>wss4j-dev-unsubscribe-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>For additional commands, e-mail: 
>>wss4j-dev-help-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
>>
>>---
>>[This E-mail scanned for viruses by Declude Virus]
> 
> 
> 
> ---
> [This E-mail scanned for viruses by Declude Virus]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> wss4j-dev-unsubscribe-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: 
> wss4j-dev-help-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
> 
>