[undertow-dev] Authentication layer in Undertow + Resteasy

[Antoine Girard]

Hi Arjan, Stuart,

Thanks for your replies. It's getting clearer and Jaspic is indeed a good
name for an elephant!
The documentation on Jaspic seems to be sparse, and I am not sure I want to
tackle it for my little "proof of concept."

I have had a deeper look at Undertow's authentication layer, and what
Stuart suggested is indeed the way to go.
It's in fact pretty much similar to what I had in mind with my custom
solution with the Jax-RS filter. So in that respect, I am reassured to see
that I was not doing something totally insane.

I am using Resteasy with the Guice extension, so I believe I will have
troubles to make the custom IdentityManager and AuthenticationMechanism
being guice managed beans, but also to have them available before the
servlet container starts (when the guice container is bootstrapped), to
register then in the DeploymentInfo! But that's something that I can solve,
I believe!

Thanks agains for your answers.

Best regards,
Antoine


On 6 January 2015 at 02:25, Stuart Douglas <sdouglas at redhat.com> wrote:

> It sounds a bit like you want a custom authentication mechanism, and the
> filter just calls HttpServletRequest.authenticate(). The mechanism has fill
> access to the exchange, so if you need to propagate some JAX-RS specific
> information you could just add it to a servlet request attribute.
>
> Stuart
>
> ----- Original Message -----
> > From: "Antoine Girard" <antoine at team51.nl>
> > To: resteasy-developers at lists.sourceforge.net,
> undertow-dev at lists.jboss.org
> > Sent: Sunday, 4 January, 2015 11:06:12 PM
> > Subject: [undertow-dev] Authentication layer in Undertow + Resteasy
> >
> > Dear fellow developers,
> >
> > I am building a small web framework based on Jax-rs (Resteasy) and
> undertow
> > (with undertow-servlet) and I am having interrogations about
> authenticating
> > requests...
> > First of all, I know I shouldn't re-invent the wheel and build another
> > framework from scratch, but I am doing it purely for educational purposes
> > (my education!)
> >
> > The setup is very simple: an embedded servlet container (undertow),
> > bootstrapping one single jax-rs servlet (resteasy), with little glue
> around
> > all of this et voilà! The user (person using the framework) only has to
> > focus on his jax-rs resources.
> >
> > The servlet api already specifies how authentication should be done, and
> > undertow implements it and I am not here to question that.
> > However, what I want to achieve is to delegate all the authentication
> logic
> > to the Jax-rs layer.
> > I see two advantages in this:
> > - The user has full control over the login / user management system,
> without
> > having to tweak the servlet deployment... He can decide to do logins
> against
> > a DB, a remote web service etc... all programatically.
> > - Use the Jax-rs "DynamicFeature" feature.. to control what resources
> have to
> > be secured. To illustrate it, here is a code sample of how I intend to
> use
> > the DynamicFeature:
> >
> > @Provider
> > public class AuthenticationNeededFeature implements DynamicFeature {
> >
> > @Inject
> > private AuthenticationFilter authenticationFilter;
> > @Override
> > public void configure(ResourceInfo resourceInfo, FeatureContext context)
> {
> >
> > /* If resource is not public then we add the authentication filter */
> > if (!resourceInfo.getResourceMethod().isAnnotationPresent(Public.class))
> {
> > context.register(authenticationFilter);
> > }
> > }
> > }
> >
> > This simply checks if the targeted resource method has the annotation
> Public
> > on it (custom annotation). If not, the resource must then be
> authenticated
> > and a ContainerRequestFilter is registered, to apply the authentication
> > logic.
> >
> > The user can do anything he wants to authenticate the request inside the
> > filter:
> > - Look in a custom Authorization header for a bearer token
> > - Validate the token against a db or a cache
> > - Play with cookies
> >
> > And more importantly, the securityContext, can be set here, as the
> Request
> > object is available.
> > The user can manufacture a securityContext containing the current user's
> > principal and roles (after a successful authentication of the request)
> and
> > therefore enable the role based access control in the resources
> > (@RolesAllowed).
> >
> > I had a little try with adding a ServletExtension into the deployment,
> with a
> > custom AuthenticationMechanism, but I couldn't achieve what is described
> > above, as it is really jax-rs specific.
> >
> > I haven't seen a lot of people on the internet doing what I have
> described
> > above... that's why I am not that confident! I am indeed bypassing all
> the
> > security layer already available in Undertow. I feel I am missing the
> > elephant in the room...
> >
> > What do you think about that approach?
> >
> > Thank you all in advance.
> >
> > Best regards,
> > Antoine
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 

*Antoine Girard // A-91*
*T.  +31(0)20 737 01 88*

*Team51 B.V.*Vlaardingenlaan 15
1062 HM  Amsterdam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150106/56c79083/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T-51 Antoine.png
Type: image/png
Size: 4748 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20150106/56c79083/attachment.png