Hi,
I fixed the tests so they don't throw exceptions anymore after a 403. Using a SNAPSHOT build from January 11, things start to get better now :)
[INFO] common ............................................ SUCCESS [1.422s]
[INFO] basic-authentication .............................. SUCCESS [5.315s]
[INFO] ejb-propagation ................................... FAILURE [5.010s]
[INFO] lifecycle ......................................... FAILURE [3.747s]
[INFO] register-session .................................. FAILURE [4.160s]
[INFO] wrapping .......................................... SUCCESS [3.739s]
ejb-propagation even partially succeeds. The authentication details are available in the public EJB bean (EJB bean without a security interceptor for @RolesAllowed), but access to a protected EJB (EJB bean with the security interceptor) fails.
This looks exactly like the bug in JBoss EAP 6.x. The security interceptor always tries to authenticate with the "security domain", where it expects a proprietary JBoss login module. I think the interceptor should just use the identity of the caller for local calls (calls to local EJB beans).
If I'm not mistaken, the entire reason to consult a security domain for every method call to an EJB bean is for remote EJB beans, not for local ones. I agree, the spec is not clear about this, but I think other servers indeed use the authenticated identity of the caller for local calls. See also the issue logged for EAP 6.x:
https://issues.jboss.org/browse/SECURITY-746
lifecycle is also failing, but this should hopefully be rather simple to fix.
register-session may be a bit more tricky. I remember it took the GlassFish guys some effort.
Btw, there are some things that historically failed on JBoss for which I haven't created tests yet, like forwarding and including from a SAM, which are now mandatory for JASPIC 1.1 (but which the TCK probably doesn't test for either).
Kind regards,
Arjan Tijms