Mailing-List: contact dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ws.apache.org
Date: Thu, 28 Aug 2014 09:45:57 +0000 (UTC)
From: "Colm O hEigeartaigh (JIRA)" <jira@apache.org>
To: dev@ws.apache.org
Message-ID: <JIRA.12737346.1409218364535.31915.1409219157741@arcas>
In-Reply-To: <JIRA.12737346.1409218364535@arcas>
References: <JIRA.12737346.1409218364535@arcas>
Subject: [jira] [Commented] (WSS-509) SecurityToken::isExpired: add clock
 skew option
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Colm O hEigeartaigh commented on WSS-509:
-----------------------------------------

What race conditions are you seeing? IMO it is not a good idea to add a "clock skew" option to the expiry of tokens. It's used in WSS4J for the "creation" of tokens only (SAML NotOnOrAfter / Timestamp Created). Why not just increase the expiry value when generating the tokens in the STS?

Colm.

> 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