[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-11604: ----------------------------------------- I see the difference now and believe this is the intended behaviour. At the moment just looking at testNonAnonymousPrincipalInjected() we have two calls: - 1 - CallerWithIdentity->BeanWithInjectedPrincipal 2 - CallerWithIdentity->BeanWithPrincipalFromEJBContext The bean CallerWithIdentity is configured with a run-as-principal of 'non-anonymous'. This run as principal affects outbound calls from this bean so when we call a different EJB the identity is switched. In scenario #2 the call is to a different EJB, this means the call passes through security interceptors which identify any outbound principal and make use of it for the next stage in the call. This is expected and in the test the expected value is being returned. In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'. If I change the call to: - 3 - CallerWithIdentity->BeanWithPrincipalFromEJBContext -> BeanWithInjectedPrincipal Now the call leaves 'CallerWithIdentity' and enters a second EJB so the run-as-principal is used, the injected CDI bean is now using the security context of the second bean so returns 'non-anonymous'. This does however leave the question regarding why the EJBContext does not report the run as principal when the call reaches the second bean, I suspect this may have been a decision during implementation as these run as scenarios were discussed quite heavily but it is purely an EJB container issue and not a CDI issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)