You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2015/01/27 16:55:35 UTC

[jira] [Resolved] (CXF-5279) STSClient may not be caching tokens long enough when renewal after expiry is allowed

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

Colm O hEigeartaigh resolved CXF-5279.
--------------------------------------
       Resolution: Fixed
    Fix Version/s: 3.0.4
         Assignee: Colm O hEigeartaigh


Fixed in 3.0.x. The token cache time is now independent on when the token actually expires.

> STSClient may not be caching tokens long enough when renewal after expiry is allowed
> ------------------------------------------------------------------------------------
>
>                 Key: CXF-5279
>                 URL: https://issues.apache.org/jira/browse/CXF-5279
>             Project: CXF
>          Issue Type: Bug
>          Components: STS
>    Affects Versions: 2.7.6
>            Reporter: Ethan Wallwork
>            Assignee: Colm O hEigeartaigh
>             Fix For: 3.0.4
>
>
> It seems that the STSClient caches tokens only for the duration where they were valid which prevents renewals after expiry.  
> In cases where renewal after expiry is allowed it is possible to renew a token after this time.  The EHCacheTokenStore calculates the TTL based on the Lifetime reported in the STS response, which in turn is calculated from the conditions on the SAML assertion.  The token will expire from the cache when the time is up, and this the STSClient can't use it to issue a renew request even if the STS allows renewals after expiry.
> Testing this was a bit tricky because it is based on caching and timeouts but I'm reasonably sure this is what's going on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)