[
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: [email protected]
For additional commands, e-mail: [email protected]
