cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-5684) Flaw in token storing logic when configured to allow token renewal after expiry
Date Mon, 14 Apr 2014 14:24:17 GMT

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

Colm O hEigeartaigh resolved CXF-5684.
--------------------------------------

    Resolution: Fixed

> Flaw in token storing logic when configured to allow token renewal after expiry
> -------------------------------------------------------------------------------
>
>                 Key: CXF-5684
>                 URL: https://issues.apache.org/jira/browse/CXF-5684
>             Project: CXF
>          Issue Type: Bug
>          Components: STS
>    Affects Versions: 2.7.10
>         Environment: Linux 3.11.0-18-generic x64, Karaf 2.3.2, OpenJDK 64-Bit Server
VM version 24.45-b08 
>            Reporter: Carma Robot
>            Assignee: Colm O hEigeartaigh
>             Fix For: 3.0.0
>
>
> There seems to be a fundamental flaw in the STS logic for token renewal when configuration
allows for renewal beyond token expiration.
> The flaw in logic seems to be in both the SAMLTokenProvider and the SAMLTokenRenewer.
In brief, when tokens are added to the default token store, and when allowRenewalAfterExipiry
is set to true, the tokens are stored in a way that causes them to expire before you can perform
a second token renewal.
> This reason why this flaw does not show up in your system tests is because you are only
testing one renewal and the logic for storing a token in SAMLTokenProvider is different than
in SAMLTokenRenewer. If you would change your renewal system test to renew the renewed token
you would catch this error.
> Here is the relevant code. I will start with SAMLTokenProvider. In the method createToken:
>             if (tokenParameters.getTokenStore() != null && signatureValue !=
null
>                 && signatureValue.length > 0) {
>                 Date expires = new Date();
>                 long currentTime = expires.getTime();
>                 expires.setTime(currentTime + (conditionsProvider.getLifetime() * 1000L));
>                 
>                 SecurityToken securityToken = new SecurityToken(assertion.getId(), null,
expires);
> The token is stored with an expiration that is essentially the current time + the lifetime
parameter. This means the token is cleared out of the cache after a period of time equal to
the "lifetime" setting. If the lifetime setting is larger than token TTL in the request submitted
by the STSClient (like in your system test) then renewal will be possible because the token
will not get cleared out of the cache before you renew.
> However, consider the logic for storing the token in SAMLRenewer.storeTokenInCache():
>         if (tokenStore != null && signatureValue != null && signatureValue.length
> 0) {
>             DateTime validTill = null;
>             if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) {
>                 validTill = assertion.getSaml2().getConditions().getNotOnOrAfter();
>             } else {
>                 validTill = assertion.getSaml1().getConditions().getNotOnOrAfter();
>             }
>             SecurityToken securityToken = new SecurityToken(assertion.getId(), null,
validTill.toDate());
> In this case you are setting the token expiration to be exactly equal to the TTL in the
request for security token. Which means that when the token expires and you try to renew the
token it's no longer in the cache!
> I believe what should be happening is that you should add the value of the SAMLTokenRenewer
maxExpiry field to the "validTill" date. Also the logic in SAMLTokenRenewer should be the
same as the logic in SAMLTokenProvider. Right now the logic is duplicated in two different
places and that can't be good for maintainability.
> I hope this is clear enough. The bottom line is that the token cache is using the expiry
that you are setting when creating the SecurityToken object to decide when to clear the token
out of the cache. If you don't set this value appropriately the token will not be in the cache
when you try to renew it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message