WebJASPIAuthenticator creates a new Subject that it passes to the JASPIC Auth Module (SAM):
Afterwards this Subject instance is put into the JBossGenericPrincipal when this is being build:
This seems to assume that the JASPIC Auth Module has populated the Subject (as happens with JAAS login modules), but this is not what happens. JASPIC Auth Modules unlike JAAS login modules are universal and have no knowledge of the container specific Subject layout.
The container should thus populate the Subject based on the callbacks.
WebJASPIAuthenticator does uses the callbacks to store the caller/user principal and roles directly into the JBossGenericPrincipal. Calls like HttpServletRequest#getUserPrincipal directly return JBossGenericPrincipal#getUserPrincipal and thus work.
However, EJBContext#getCallerPrincipal() which is implemented by org.jboss.as.security.service.SimpleSecurityManager#getCallerPrincipal works with securityContext.getSubjectInfo().getAuthenticatedSubject and does not work.
This SubjectInfo is initialized in org.jboss.as.web.security.SecurityContextAssociationValve via the following code:
(principal here is the JBossGenericPrincipal that's returned by WebJASPIAuthenticator)
Because the Subject instance used here is still the empty instance, the authenticated identity will not be available in EJB beans. EJBContext#getCallerPrincipal() will always return the anonymous principal and every check for a role will return false.
Adding something like the following code to buildJBossPrincipal seems to propagate the authenticated identity correctly to the EJB module:
I've tested locally with this patch and it indeed seems to work.