[undertow-dev] Authentication layer in Undertow + Resteasy

[Stuart Douglas]

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