ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: WSS4J Timestamp validation for incoming messages confusion
Date Thu, 31 May 2012 15:23:13 GMT
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 <JvanTonder@fnb.co.za>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 :: Mobile: +27 83 417 5424
> e-mail: jvantonder@fnb.co.za :: 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
> firstrandbankdisclaimer@fnb.co.za and we will send you a copy of the
> Disclaimer.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message