Hi, thank you for your response but I still don't understand a few things, especially what do you mean by "The cxf-bc consumer then uses alice.properties (signaturePropFile) to validate against information in bob.properties (encryptionPropFile)." aren't signature and encryption separate machanisms?
In the example there's both encryption and signature used in both directiosn so both client and server need to have two keys: its own private and other side's public, so how they are located in alice.jks and bob.jks? And I'm thinking only about singature without encrypting content, in such case the client should have its private key and the server should have matching public key to verify that that's the real client, is that enough to implement one-way signature? Ashwin Karpe wrote: > > Hi Lukasz, > > In the example alice.jks is the public key sent by the client and bob.jks > is the private key with whom it is matched on the server. > > The main thing to know is that the client only knows about alice.jks and > the server only knows bob.jks. > > The client uses alice.properties which contains the details for the > location of the alice.jks file to timestamp encrpt the message in its cxf > out interceptor. The cxf-bc consumer then uses alice.properties > (signaturePropFile) to validate against information in bob.properties > (encryptionPropFile). On the outbound the consumer then uses the private > key in its out interceptor i.e bob.properties (signaturePropFile) to > timestamp encrypt the outgoing response to be matched against alice.jks > (encryptionPropFile) in the client. > > Note the order of the signatureProp file to figure out what is used to > encrypt and the encryptionPropFile to figure out what key is used to > verify the match... > > Hope this helps. > > Cheers, > > Ashwin... > -- View this message in context: http://www.nabble.com/CXF-WSS-example-tp20857457p20869922.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
