coheigea wrote > In any case, the IssuedTokenInterceptorProvider in CXF is token-agnostic, > and so I > don't want to introduce token-specific parsing here. > Colm.
Good point, I can understand that logic then. I suppose if someone wants to there would be a way to plug in their own cache management. Just very confusing when service provide validates SAML and looks only at the NotOnOrAfter for its expiry check. I could not find any documentation on this tricky subject anywhere. Perhaps this could warrant a blog post or document note somewhere as I ran across similar posts like mine on StackOverflow <http://stackoverflow.com/questions/18456870/apache-cxf-ws-trust-sts-token-expires-but-wont-renew> . But thanks for the great and quick response, your hint of lifetime got me looking at the settings on my STS and once I had it put this element in the RSTR and make it less then NotOnOrAfter, I was all working. Thanks Colm! -- View this message in context: http://cxf.547215.n5.nabble.com/Clarification-of-CXF-client-handling-of-expired-cached-tokens-tp5743216p5743269.html Sent from the cxf-user mailing list archive at Nabble.com.
