[
https://issues.apache.org/jira/browse/CXF-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125683#comment-14125683
]
Colm O hEigeartaigh commented on CXF-5975:
------------------------------------------
What race conditions have you seen? I'm not keen on adding this option to
SecurityToken. If the token has expired + you are seeing a subsequent race
condition, then it is a bug that we should fix.
Colm.
> 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)
