cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Salembier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5975) SecurityToken::isExpired: add clock skew option
Date Mon, 08 Sep 2014 17:51:28 GMT

    [ 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)

Mime
View raw message