Willem Salembier created WSS-509:
------------------------------------
Summary: 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]
