[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    [jira] [Closed] (WSS-509) SecurityToken::isExpired: add clock skew option
From:       "Colm O hEigeartaigh (JIRA)" <jira () apache ! org>
Date:       2014-08-28 10:15:58
Message-ID: JIRA.12737346.1409218364535.32086.1409220958007 () arcas
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/WSS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Colm O hEigeartaigh closed WSS-509.
-----------------------------------

    Resolution: Won't Fix

> 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


[prev in list] [next in list] [prev in thread] [next in thread]