ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Salembier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WSS-509) SecurityToken::isExpired: add clock skew option
Date Thu, 28 Aug 2014 09:51:58 GMT

    [ https://issues.apache.org/jira/browse/WSS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113620#comment-14113620
] 

Willem Salembier commented on WSS-509:
--------------------------------------

An alternate possibility is to subclass STSClient and substract the clock compensation in
the createSecurityToken method.

{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}

> SecurityToken::isExpired: add clock skew option
> -----------------------------------------------
>
>                 Key: WSS-509
>                 URL: https://issues.apache.org/jira/browse/WSS-509
>             Project: WSS4J
>          Issue Type: Improvement
>          Components: WSS4J Core
>    Affects Versions: 1.6.16
>            Reporter: Willem Salembier
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.6.17
>
>
> 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()
cfr whats been done in org.apache.ws.security.validate.SamlAssertionValidator.checkConditions(AssertionWrapper)
with the futureTTL property. In SamlAssertionValidator the futureTTl is only used in the validFrom
comparison, but in our case it should be considered also in the validTill comparison.
> A possible workaround is to configure our STS to initialize Lifetime>Expires in the
RSTR response to SAMLAssertion > Conditions > NotOnOrAfter - clock skew.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message