Hi Colm, unfortunately only the timestamp and the SAML assertion are signed, not the message Id.
As far as I can tell per xml schema and soap message security specifications there isn't a requirement on the precision for the timestamp, meaning if a timestamp was created with just a year, my service might detect all other messages that year as replays. Which doesn't seem right to me (even if it where seconds or milliseconds). I think for now I'm just planning on disabling this feature using the <entry key="ws-security.enable.timestamp.cache" value="false" /> in our endpoint definition. Is there a way to do this via a JVM option instead of editing all of my endpoint definitions? On Fri, Mar 7, 2014 at 5:25 AM, Colm O hEigeartaigh <[email protected]>wrote: > Hi Matthew, > > > I might be interested in figuring out how to add wsa:messageId in to the > detection mix... > > It already is if it is signed. Does the service already require > WS-Addressing? If so and if you add a "SignedPart" policy like: > > <sp:Header Name="MessageID" Namespace=" > http://www.w3.org/2005/08/addressing > "/> > > then the SignatureValue should be different for each Signature, even if > they are signing the same Timestamp Created value. > > Colm. > > > On Fri, Mar 7, 2014 at 1:14 AM, matthew weaver <[email protected]> > wrote: > > > Hi. I have read some good info ( > > > > > http://coheigea.blogspot.com/2012/04/security-token-caching-in-apache-cxf-26.html > > ) > > and dug through CXF code regarding the feature for detecting replayed > > messages. I have run into an issue processing multiple messages of the > > following scenario: > > 1) Another web service stack is sending my CXF service messages with a > > wsu:Timestamp/wsu:Created that is only precise to the seconds as opposed > to > > milliseconds. > > 2) Two messages are sent within the same second. I.E. They have the same > > timestamp. > > 3) These message has 2 digital signatures on it. One on the timestamp and > > the other on a SAML 2.0 assertion. > > 4) The assertion and therefore assertion signature are legitimately > > identical for the two messages. > > 5) Because the timestamp/timestamp signature and the timestamp/assertion > > signature are the same for the two messages, a replay is detected. > > > > In this scenario, I believe the replay detection functionality is > detecting > > false positives. I have two questions: > > 1) Is my understanding correct and is this expected behavior? I might be > > interested in figuring out how to add wsa:messageId in to the detection > > mix... > > 2) How can I override this behavior? I.E. Which interfaces would I > > implement? > > > > Thank you! > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
