[jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

[Ivo Studensky (JIRA)]

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

Ivo Studensky edited comment on SECURITY-868 at 5/22/15 6:55 AM:
-----------------------------------------------------------------

My understandings so far:

1. Thread A is entering  {{org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingPolicyInterceptor#handleMessage()}} via {{org.apache.cxf.phase.PhaseInterceptorChain.doIntercept()}}. The SubjectCreatingPolicyInterceptor invokes {{org.jboss.wsf.stack.cxf.security.authentication.SubjectCreator#createSubject()}} which firstly sets a callback handler at line 86.
{code:java}
         CallbackHandler handler = new UsernameTokenCallbackHandler(nonce, created, decodeNonce);
         CallbackHandlerPolicyContextHandler.setCallbackHandler(handler);
{code}
Then, it successfully authenticates an user and in the finally block it sets the callback handler to {{null}} at line 123.
{code:java}
         CallbackHandlerPolicyContextHandler.setCallbackHandler(null);
{code}

2. Thread B authenticates the same user and updates a cache entry for the same principal as Thread A with different credentials. This invalidates the cache entry for Thread A for further usage.

3. Thread A is entering {{org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage()}} via {{org.apache.cxf.phase.PhaseInterceptorChain.doIntercept()}}. The ServiceInvokerInterceptor invokes an EE ViewService related to the EJB3 Endpoint of the Web Service being invoked which goes through EJB Interceptors and especially {{org.jboss.as.ejb3.security.SecurityContextInterceptor}}. The SecurityContextInterceptor tries to authenticate the user against the cache which has been invalidated by Thread B in the meantime which leads to a new invocation of  JAAS login module, i.e. UsernamePasswordLoginModule, which then fails due to {{null}} callback handler.

I am not sure if this can be easily fixed. It doesn't , however, look like a PicketBox issue as it is CXF which nulls the callback handler before invocation of the ServiceInvokerInterceptor phase. For this use-case it seems the cache on the security domain has to be disabled.



was (Author: istudens):
My understandings so far:

1. Thread A is entering  {{org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingPolicyInterceptor#handleMessage()}} via {{org.apache.cxf.phase.PhaseInterceptorChain.doIntercept()}}. The SubjectCreatingPolicyInterceptor invokes {{org.jboss.wsf.stack.cxf.security.authentication.SubjectCreator#createSubject()}} which firstly sets a callback handler at line 86.
{code:java}
         CallbackHandler handler = new UsernameTokenCallbackHandler(nonce, created, decodeNonce);
         CallbackHandlerPolicyContextHandler.setCallbackHandler(handler);
{code}
Then, it successfully authenticates an user and in the finally block it sets the callback handler to {{null}} at line 123.
{code:java}
         CallbackHandlerPolicyContextHandler.setCallbackHandler(null);
{code}

2. Thread B authenticates the same user and updates a cache entry for the same principal as Thread A with different credentials. This invalidates the cache entry for Thread A for further usage.

3. Thread A is entering {{org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage()}} via {{org.apache.cxf.phase.PhaseInterceptorChain.doIntercept()}}. The ServiceInvokerInterceptor invokes an EE ViewService related to the Web Service being invoked which goes through EJB Interceptors and especially {{org.jboss.as.ejb3.security.SecurityContextInterceptor}}. The SecurityContextInterceptor tries to authenticate the user against the cache which has been invalidated by Thread B in the meantime which leads to a new invocation of  JAAS login module, i.e. UsernamePasswordLoginModule, which then fails due to {{null}} callback handler.

I am not sure if this can be easily fixed. It doesn't , however, look like a PicketBox issue as it is CXF which nulls the callback handler before invocation of the ServiceInvokerInterceptor phase. For this use-case it seems the cache on the security domain has to be disabled.


> Multithread issue when validate with cached hased password + nonce credential  info from JBossCachedAuthenticationManager 
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-868
>                 URL: https://issues.jboss.org/browse/SECURITY-868
>             Project: PicketBox 
>          Issue Type: Task
>          Components: PicketBox
>            Reporter: Jim Ma
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_9_0.Final
>
>         Attachments: stacktraces.log
>
>
> When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager,  thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A,  the cached validation info won't work and following validation with cached credential will all fail. 



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