Correct, and after digging around in the source for WildFly came to near enough the same conclusion. And yes I agree, and personally, I would LOVE to upgrade to 11, or even 10 at this point, but out of my hands at the moment. One other thing I discovered, once I turned on trace logging for JBoss security items, was that my calls to sc.login() were actually failing, but not being reported at all, and this was actually causing the infinite recursion. I did manage to come up with what seems like a more appropriate solution, so I'll run down what I did and see if it's a terrible idea. Setup: Application is configured with a security domain in the WildFly config. The web.xml has normal security and roles defined in there, as well as the custom auth method. Deployed an an EAR with an EJB project. EJBs have @SecurityDomain on them and @RolesAllowed annotations defined Custom Auth Mechnanism: Simple class reading a JWT based cookie to get auth info. Calls SecurityContext.authenticationComplete with Account details. (no use of IdentityManager or anything else as other posts have mentioned) Works with this at web layer, but not in EJB layer. So... Solution: Write a custom login module and add it to security domain config, extending AbstractServerLoginModule. <hack?> In AuthMechanism, on successful auth a ThreadLocal variable is set with the account info SecurityContext.login() is called which calls the login module which reads the ThreadLocal variable from the auth mechanism. Roles are pulled from the getRoleSet method implementation. User is now logged in as far the security domain is concerned with the correct roles. </hack?> I feel more comfortable now that I least know whats going on and the complete flow, but it still doesn't feel very nice. Reading through the code I can kind of see why the 'extra' SecurityContext.login is required, but would be nice if this was not a requirement. Not very intuitive that you are completing the authentication, but are not seen as completely logged in. It looks like changes would be required at the configuration level to somehow be aware of the customer auth mechanism for something like this to work. Does this feel like a completely unreasonable request? I'm an (obvious) novice on JAAS side of things, but if this is not completely of base I'll be happy to file a feature request for this type of setup. I feel like it's already so close. Thoughts? Feedback? Thanks for the time! -Nick On Tue, Oct 31, 2017 at 5:51 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote:

FYI I am just in the process of planning the WildFly Elytron / JASPIC implementation, this doc is far from complete but I am currently assembling my thoughts and plans here: - https://developer.jboss.org/wiki/AnalysisDesign-JASPICIntegrationWithWild... Most importantly this will also be a move to support true config provider matching without requiring a deployment to be artificially associated to a security domain just to switch on JASPIC support. Regards, Darran Lofthouse. On Tue, 31 Oct 2017 at 23:12 arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: