[
https://issues.apache.org/jira/browse/CXF-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146376#comment-14146376
]
Colm O hEigeartaigh commented on CXF-5975:
------------------------------------------
I've added a new JAX-WS configuration tag to SecurityConstants:
/**
* This is the value in seconds within which a token is considered to be
expired by the
* client. When a cached token (from a STS) is retrieved by the client, it
is considered
* to be expired if it will expire in a time less than the value specified
by this tag.
* This prevents token expiry when the message is en route / being
processed by the
* service. When the token is found to be expired then it will be renewed
via the STS.
*
* The default value is 10 (seconds). Specify 0 to avoid this check.
*/
public static final String STS_TOKEN_IMMINENT_EXPIRY_VALUE =
"ws-security.sts.token.imminent-expiry-value";
So for CXF 3.0.2 it will renew the token if it is about to expire within 10
seconds. For CXF 2.7.13 this is not enabled by default in case it breaks
previous deployments. In this case you will have to set the configuration tag
explicitly to "10" (or however many seconds you want).
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
> Assignee: Colm O hEigeartaigh
> Fix For: 2.7.13, 3.0.2
>
>
> 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)
