CXF 2.7.7. Service is expecting SAML 2 tokens via IssuedToken policy. The token that the STS issued via the CXF STSClient expires after 5 minutes. After 5 minutes is when my service is rejecting the token as expected and throwing a SOAP fault for token expired.
Error is: "SAML Token condition (Not On Or After) not met" thrown via SamlAssertionValidator My confusion here is that I had expected CXF to handle expiring tokens on the client in either one of 2 ways: 1. Token implementation removes expired tokens from the client side ws-security cache automatically when they are expired thus preventing CXF client from grabbing a useless/expired token from the cache 2. jax-ws client determines token from the cache is expired, requests or removes such token from cache, then creates a new issue or renew request to STS to obtain a new token Per this article: http://coheigea.blogspot.com/2012/04/security-token-caching-in-apache-cxf-26_25.html CXF caches tokens in the security runtime in the following circumstances: - When the IssuedTokenInterceptorProvider is invoked to obtain an Issued token from an STS. - When the STSTokenValidator is used to validate a received UsernameToken, BinarySecurityToken or SAML Assertion to an STS. It states: "Tokens are stored until the expiry date of the token if it exists.." My question is what is responsible for removing expired tokens from the cache? As it seems this is not happening. But then when I look at documentation for Token Cache it states: "It is up to the underlying implementation to handle token expiration" Once the initial token is provided via STS, no other calls are done to STS again via the STSClient and my assumption is it keeps grabbing the expired SAML token from the client side cache. Thus I have to bounce my JVM in order to test the STS and service again. -- View this message in context: http://cxf.547215.n5.nabble.com/Clarification-of-CXF-client-handling-of-expired-cached-tokens-tp5743216.html Sent from the cxf-user mailing list archive at Nabble.com.
