Colm, Thank you for the explanation. That clears up my confusion and it makes sense in the context of enforcing a limit at the server/recipient side. :)
Regards, ---Jaco On 31/05/2012 17:23, Colm O hEigeartaigh wrote: Hi Jaco, > Looking at the code I can see that the default TTL (300) is being used > to calculate the valid time for creation even though both the created > and expiry times are set. > Is this behavior correct? Should the TTL not be ignored when validating > incoming messages? I fail to see how TTL should play a part when doing > this validation for the creation date of *incoming* messages. TTL is used on the incoming side to make sure that the message was not created "too long ago". The longer a message can be considered valid, the greater the range of time an adversary will have to create a message replay attack. The client can use the Expiry time to enforce a restriction on the time validity of the message. TTL is a way for the message recipient to enforce its own restriction on the time validity of the message. In your example, the difference between Created and Expires is one hour, and so I suggest you adjust the TTL value on the recipient side accordingly if you want to accomodate this time difference. Colm. On Thu, May 31, 2012 at 4:02 PM, Van Tonder, Jaco <[email protected]<mailto:[email protected]>> wrote: Hello guys, I am a bit confused about how Timestamp validation for incoming messages work in WSS4J. The current situation is that I have a CXF web service provider (WSS4J 1.6.3) validating a timestamp on an incoming message, but failing even though the current date (on the server side) is right in the middle of the <wsu:CreatedDate /> and <wsu:ExpiryDate/> elements specified by the client. Here are the relevant parts from the logs (I added more debug messages): 2012-05-31 15:59:40.798 DEBUG SignatureProcessor:325 - Verify XML Signature 2012-05-31 15:59:40.808 DEBUG TimestampProcessor:43 - Found Timestamp list element 2012-05-31 15:59:40.808 DEBUG Timestamp:151 - Current time: 2012-05-31T13:59:40.808Z 2012-05-31 15:59:40.809 DEBUG Timestamp:156 - Timestamp created: 2012-05-31T13:53:26.226Z 2012-05-31 15:59:40.810 DEBUG Timestamp:162 - Timestamp expires: 2012-05-31T14:53:26.226Z 2012-05-31 15:59:40.811 DEBUG TimestampProcessor:53 - Timestamp ID =[TS-1] 2012-05-31 15:59:40.811 DEBUG TimestampValidator:62 - wssConfig element exist, setting timestamp related values: 2012-05-31 15:59:40.812 DEBUG TimestampValidator:63 - timeStampStrict=[true] 2012-05-31 15:59:40.812 DEBUG TimestampValidator:65 - timeStampTTL=[300] 2012-05-31 15:59:40.813 DEBUG TimestampValidator:66 - futureTimeToLive=[60] 2012-05-31 15:59:40.813 DEBUG Timestamp:317 - verifyCreated() got values: ttl=[300], future ttl=[60] 2012-05-31 15:59:40.814 DEBUG Timestamp:340 - Validation of Timestamp: The message was created too long ago. createdDate=[2012-05-31T13:53:26.226Z], validCreation=[2012-05-31T13:54:40.808Z] May 31, 2012 3:59:40 PM org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage WARNING: org.apache.ws.security.WSSecurityException: The message has expired (WSSecurityEngine: Invalid timestamp The security semantics of the message have expired) Looking at the code I can see that the default TTL (300) is being used to calculate the valid time for creation even though both the created and expiry times are set. Is this behavior correct? Should the TTL not be ignored when validating incoming messages? I fail to see how TTL should play a part when doing this validation for the creation date of *incoming* messages. Should the TTL play any part on the web service provider side (maybe to enforce a specific timeframe)? The code in question: [1] http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/validate/TimestampValidator.java?revision=1130107&view=markup (line 60-65) [2] http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/message/token/Timestamp.java?view=markup (line 304-345) I will create a JIRA for this if someone could just verify that what I am saying makes sense. :) Thank you in advance. ---Jaco -- Jaco van Tonder Application Infrastructure: Analyst Programmer First National Bank: Hogan Technology 3 First Place Bank City Corner Simmonds and Jeppe Streets Johannesburg Direct: +27 87 736 1790<tel:%2B27%2087%20736%201790> :: Mobile: +27 83 417 5424<tel:%2B27%2083%20417%205424> e-mail: [email protected]<mailto:[email protected]> :: Web: http://www.fnb.co.za/ To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser: https://www.fnb.co.za/disclaimer.html If you are unable to access the Disclaimer, send a blank e-mail to [email protected]<mailto:[email protected]> and we will send you a copy of the Disclaimer. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com -- Jaco van Tonder Application Infrastructure: Analyst Programmer First National Bank: Hogan Technology 3 First Place Bank City Corner Simmonds and Jeppe Streets Johannesburg Direct: +27 87 736 1790 :: Mobile: +27 83 417 5424 e-mail: [email protected]<mailto:[email protected]> :: Web: http://www.fnb.co.za/ To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser: https://www.fnb.co.za/disclaimer.html If you are unable to access the Disclaimer, send a blank e-mail to [email protected] and we will send you a copy of the Disclaimer.
