[
https://issues.apache.org/jira/browse/CXF-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125817#comment-14125817
]
Willem Salembier commented on CXF-5975:
---------------------------------------
Race condition is perhaps bad wording. The situation with some clients is the
following.
token valid from 0:00:00->0:59:59
0:59:59: CXF verifies token expiration on client side and determines its valid
-- network traffic / wire time --
1:00:00: token arrives on server and server rejects it because token is expired.
To handle this situation:
1) Either the server should be lax and accept tokens that expired in the last x
seconds
2) Either the client should be defensive and don't use a token that will expire
within x seconds
3) Either the client should on receiving a soap fault, automically renew the
token and resubmit the request
In our situation we cannot change the server (option 1) and option 2 and 3 are
not currently not supported in CXF thus the only thing we can do is implement
the retry in our client code explicitely.
I'd prefer a simple configuration feature of the CXF token cache to instruct
that tokens expiring within x seconds must be renewed by force (eg like in the
example above)
> SecurityToken::isExpired: add clock skew option
> -----------------------------------------------
>
> Key: CXF-5975
> URL: https://issues.apache.org/jira/browse/CXF-5975
> Project: CXF
> Issue Type: Improvement
> Affects Versions: 2.7.10, 2.7.12
> Reporter: Willem Salembier
> Fix For: 2.7.13
>
>
> We notice race conditions with some of our clients when CXF verifies if
> SecurityTokens cached locally are still valid or expired. One reason could be
> clock desynchronization, another reason is that while the token was still
> valid at the moment of request construction, it isn't when the SOAP message
> arrives on the server (1s difference suffices).
> Is it possible to add a clock skew option to
> org.apache.cxf.ws.security.tokenstore.SecurityToken.isExpired() or
> org.apache.cxf.ws.security.trust.STSClient to compensate clock differences
> between client and server.
> Our current workaround is to subclass the STSClient class.
> {code}
> public class STSClockSkewClient extends STSClient {
> private static final int CLOCK_SKEW = 15 * 1000 /* 15s */;
> public STSClockSkewClient(Bus b) {
> super(b);
> }
> @Override
> protected SecurityToken createSecurityToken(Element el, byte[]
> requestorEntropy) throws WSSecurityException {
> SecurityToken securityToken = super.createSecurityToken(el,
> requestorEntropy);
> Date expires = securityToken.getExpires();
> if (expires != null) {
> securityToken.setExpires(new Date(expires.getTime() -
> CLOCK_SKEW));
> }
> return securityToken;
> }
> }
> {code}
> A possible workaround is to handle this in the STS and set Lifetime>Expires
> in the RSTR response not equal but some time before the end of the SAML
> token, but most of the times the STS clients have no control over the STS
> service and cannot ask the service provider to make this change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
