You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Blue Diamond <gv...@gmail.com> on 2011/04/29 15:10:30 UTC
Timing issue with WS-Security
I am getting the following exception with WS-Security when machines from
different timezones are working together.
javax.xml.ws.WebServiceException: The message has expired (WSSecurityEngine:
Invalid timestamp The security semantics of the message have expired)
I think there is a way to add tolerance (say 1 - 2 minutes delay) in
WS-Security Policy when using <IncludeTimestamp>. Can someone please help
with this?
Thanks & Regards,
Anil
Re: Timing issue with WS-Security
Posted by Blue Diamond <gv...@gmail.com>.
tatz gr8.. thanks a lot Daniel :)
On Fri, Apr 29, 2011 at 11:26 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Friday, April 29, 2011 9:10:30 AM Blue Diamond wrote:
> > I am getting the following exception with WS-Security when machines from
> > different timezones are working together.
> >
> > javax.xml.ws.WebServiceException: The message has expired
> > (WSSecurityEngine: Invalid timestamp The security semantics of the
> message
> > have expired)
> >
> > I think there is a way to add tolerance (say 1 - 2 minutes delay) in
> > WS-Security Policy when using <IncludeTimestamp>. Can someone please help
> > with this?
>
> With CXF 2.4.0, there are a couple of settings that allow a bit of a
> tolerance
> for "future" timestamps.
>
> The setting:
> "ws-security.timestamp.futureTimeToLive" (in seconds)
>
> has javadoc of:
> This configuration tag specifies the time in seconds in the future within
> which the Created time of an incoming Timestamp is valid. WSS4J rejects by
> default any timestamp which is "Created" in the future, and so there could
> potentially be problems in a scenario where a client's clock is slightly
> askew. The default value for this parameter is "0", meaning that no future-
> created Timestamps are allowed.
>
> which may be what you need.
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Timing issue with WS-Security
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, April 29, 2011 9:10:30 AM Blue Diamond wrote:
> I am getting the following exception with WS-Security when machines from
> different timezones are working together.
>
> javax.xml.ws.WebServiceException: The message has expired
> (WSSecurityEngine: Invalid timestamp The security semantics of the message
> have expired)
>
> I think there is a way to add tolerance (say 1 - 2 minutes delay) in
> WS-Security Policy when using <IncludeTimestamp>. Can someone please help
> with this?
With CXF 2.4.0, there are a couple of settings that allow a bit of a tolerance
for "future" timestamps.
The setting:
"ws-security.timestamp.futureTimeToLive" (in seconds)
has javadoc of:
This configuration tag specifies the time in seconds in the future within
which the Created time of an incoming Timestamp is valid. WSS4J rejects by
default any timestamp which is "Created" in the future, and so there could
potentially be problems in a scenario where a client's clock is slightly
askew. The default value for this parameter is "0", meaning that no future-
created Timestamps are allowed.
which may be what you need.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com