The issue WFLY-140 introduced a change in behavior.

Before this change, the SecurityContextInterceptor would just invoke the push() method on SimpleSecurityManager and that method would internally create a new security context and authenticate the incoming principal if needed. In that implementation the presence of a RunAsIdentity would cause authentication part to be skipped.

With the changes in the above issue, the security context establishment and the authentication parts were separated and while push() still checks for a RunAsIdentity, the authenticate() implementation does not, which ends up triggering the authentication process even if a RunAsIdentity is available. There is another check in place to avoid authentication if a valid authenticated subject already exists and the security domains match but this should also be the case if the security domains do not match.