Hi, > 1. Would this mean I have to configure a Asym or Sym security binding in > addition to TLS policy, so as to enable the signing part?
No, instead you would have a TransportBinding policy where a client certificate is not required, and you have an EndorsingSupportingTokens policy which specifies an X509Token. This policy means that TLS is used (without a client cert), and the private key corresponding to the X509Token must "endorse" the message, which means it signs the Timestamp (as well as any other SignedParts that are specified). See the following WSDL for an example policy (search for "DoubleItTransportEndorsingPolicy"): http://svn.apache.org/viewvc/cxf/trunk/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/x509/DoubleItX509.wsdl?view=markup > 2. If I want signing present only on the incoming message, would Asym or Sym > policy complain. Most configurations highlight both Initiator and Recepient > token sections and I am not clear if I the specs mandate signing both ways. It should work ok, just specify an Input policy of what to sign, and not an Output policy. Colm. On Sat, Feb 4, 2012 at 3:42 PM, sram <[email protected]> wrote: > I'm working on a use case where I need to uniquely identify (in secured > fashion, no compromise) all clients reaching my endpoint and take measures > based on it. All clients will use common TLS infrastructure; when I > configure my security policy, what would be my best options without > overdoing or complicating client side implementation. > > I'm thinking in lines of signing parts of message using clients keystore, > which will be unique for each. The question' are, > > 1. Would this mean I have to configure a Asym or Sym security binding in > addition to TLS policy, so as to enable the signing part? > 2. If I want signing present only on the incoming message, would Asym or Sym > policy complain. Most configurations highlight both Initiator and Recepient > token sections and I am not clear if I the specs mandate signing both ways. > > Any suggestions would help. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/SecurityPolicy-Option-tp5456290p5456290.html > Sent from the cxf-user mailing list archive at Nabble.com. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
