[jboss-jira] [JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability

[Ivo Studensky (JIRA)]

    [ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069604#comment-13069604 ] 

Ivo Studensky commented on SECURITY-882:
----------------------------------------

The fix for SECURITY-868 seems to be broken. It does not call {{validatedDomainInfo.remove()}} at {{JBossCachedAuthenticationManager#logout()}}. Furthermore, there is no guarantee that {{logout()}} is called on every thread on which login was called in the past. Hence, any thread-local does not seem to be the right way to fix SECURITY-868.

A proper fix might be to cache credentials by username + nonce as credentials are actually different for each such a pair.

> Fix for SECURITY-868 breaks flush-cache capability
> --------------------------------------------------
>
>                 Key: SECURITY-882
>                 URL: https://issues.jboss.org/browse/SECURITY-882
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: AS-Integration
>    Affects Versions: PicketBox_4_0_19.Final
>         Environment: EAP 6.3.3, JDV 6.1.0
>            Reporter: Hisanobu Okuda
>            Assignee: Stefan Guilhen
>
> The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)