[undertow-dev] WildFly 8.2.1 EJB Security and Custom Auth Mechanism.

Nick Stuart nick at portlandwebworks.com
Wed Nov 1 08:41:35 EDT 2017


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 at redhat.com> wrote:

> I assume you are not using the IdentityManager in your custom impl?
>
> This is what causes the Wildfly issues, as the Wildfly SecurityContext
> setup is done there. You will probably need to duplicate some of the
> code in org.wildfly.extension.undertow.security.JAASIdentityManagerImpl
> into your custom auth mechanism (the bit in
> org.wildfly.extension.undertow.security.JAASIdentityManagerImpl#
> verifyCredential
> that sets up the context).
>
> I would recomment upgrading to Wildfly 11, there have been a *lot* of
> fixes since 8.1.
>
> Stuart
>
> On Wed, Nov 1, 2017 at 1:04 AM, Nick Stuart <nick at portlandwebworks.com>
> wrote:
> > Hello all, having an issue with a custom
> > io.undertow.security.api.AuthenticationMechanism implementation and EJB
> > security on WildFly 8.2 and hoping someone can think of a work around.
> >
> > Basic problem, user is authenticated via the AuthenticationMechanism, and
> > the web context sees the user just fine and their roles, but when we get
> to
> > the EJB calls the user is seen as 'anonymous'. The mechanism calls:
> >
> > sc.authenticationComplete(ac, mechanismName, true);
> > and returns:
> > AuthenticationMechanismOutcome.AUTHENTICATED;
> >
> > The resources I'm calling are configured as being protected through the
> > web.xml and all of that is working as expected.
> >
> > Another note, I am able to get this to work in WildFly 10.1, but only
> with
> > (what I think is) a bit of hack. The following code is required for EJB
> > Security to work:
> >
> >     sc.authenticationComplete(ac, mechanismName, true);
> >     sc.login(ac.getUsername(), "");
> >     sc.authenticate();
> >
> > This same code in 8.2 causes an infinite recursion issue. Even working
> > around that (with another hack) this still doesn't work.
> >
> > Any ideas would be greatly appreciated. Upgrading is going to be
> considered
> > a worst case scenario right now, and would like avoid it right now if at
> all
> > possible.
> >
> > Thanks for the help!
> > -Nick
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20171101/c372e641/attachment.html 


More information about the undertow-dev mailing list