[wildfly-dev] Calling attention to two security bugs in WildFly

[Stefan Guilhen]

I'll move these issues over to WildFly as they have nothing to do with 
PicketBox. I'm currently looking into 876 (logout not clearing the 
context) and it should be fixed for WF9.

Regarding SECURITY-746, historically the EJB container has always setup 
a new security context when a call is made to a protected EJB. There is 
no mechanism in place to skip any authentication and just trust the 
incoming context. The Elytron project will tackle the security context 
propagation issues that we have today, so anything we code for WF9 in 
that sense will be just a temporary band aid.

Its also worth saying that this issue affects mainly apps that use 
JASPIC for authentication - most of the time applications use regular 
JAAS based security domains so usually the same domain and login modules 
are involved in both Web and EJB authentication. When using JASPIC, the 
EJB app might need a different domain configuration to handle its 
authentication, which is an annoyance. Anil tried getting around that in 
the past by setting the so called "login-module-stack" in the JASPIC 
configuration, so that both Web and EJB layers would end up doing the 
regular JAAS based login and thus you wouldn't need a different domain 
configuration. However, a JASPIC module is not required to go through 
JAAS, so I can see why that can be a problem.

That being said, one possible solution would be to reuse the incoming 
context if it already contains an authenticated subject and if the 
security domain of the incoming context matches the one configured in 
the EJB app. This would probably need a flag like 
"trust-incoming-security-context" in the EJB subsystem because it will 
change how the server handles authentication in EJB container and how 
existing apps are protected. The default value would be false to 
preserve current behavior but one could change it to true in order to 
reuse the context that was established in the Web layer. Of course, if 
the EJB app defines a different security domain then we create a new 
context and enforce authentication against this domain instead of 
trusting an incoming security context.

It is not the best solution but might be ok as a workaround until 
Elytron gets properly integrated.

On 05/05/2015 08:21 PM, arjan tijms wrote:
> Hi,
>
> A while back I reported https://issues.jboss.org/browse/SECURITY-746 
> and https://issues.jboss.org/browse/SECURITY-876
>
> 746 has been open for a long time, while 876 is relatively new.
>
> Both concern propagation of the authenticated identity from Servlet to 
> EJB, something which unfortunately has seen bugs in some form of the 
> other for several years now.
>
> Would really be great if this can be fixed. I provided a possible 
> workaround for 876, and a reproducer test for both issues. If needed I 
> can help more.
>
> Kind regards,
> Arjan Tijms
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150507/311a9c54/attachment.html