Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 22 Nov 2016 17:43:58 +0000 (UTC)
From: "Colm O hEigeartaigh (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.13022551.1479834620000.340935.1479836638446@Atlassian.JIRA>
In-Reply-To: <JIRA.13022551.1479834620000@Atlassian.JIRA>
References: <JIRA.13022551.1479834620000@Atlassian.JIRA> <JIRA.13022551.1479834620164@arcas>
Subject: [jira] [Commented] (CXF-7148) Race Condition while handling
 symmetric key in SymmetricBindingHandler
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 22 Nov 2016 17:44:05 -0000


    [ https://issues.apache.org/jira/browse/CXF-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687380#comment-15687380 ] 

Colm O hEigeartaigh commented on CXF-7148:
------------------------------------------

We need to cache SecurityTokens to make sure that we have access to the symmetric key when processing the response. I think the problem here is that the key used to cache the tokens is dependent on the request. CXF uses random wsu:Ids, but other stacks do not. I'll take a look at this tomorrow.

Colm.

> Race Condition while handling symmetric key in SymmetricBindingHandler
> ----------------------------------------------------------------------
>
>                 Key: CXF-7148
>                 URL: https://issues.apache.org/jira/browse/CXF-7148
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 3.1.7, 3.1.8
>            Reporter: Max Fichtelmann
>            Assignee: Colm O hEigeartaigh
>
> when using an asymmetricBinding, when requested in parallel, quite a few requests fail, where the client could not associate a symmetric key with the response.
> As it turned out, the symmetric key was stored temporarily in a cache using an id that is not unique at all.
> {code:title=SymmetricBindingHandler.java|borderStyle=solid}
> // line 985 via 162
> tokenStore.add(tempTok);
> // line 182
> tok = tokenStore.getToken(tokenId);
> {code}
> This leads to a race condition if another thread reaches line 162 before the key is retrieved in 182 and the same id is used.
> In my case, the id was "_5002" consistently.
> We implemented a hack using a ThreadLocal based TokenStore, but I think the symmetric key should actually not be cached at all.


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