6:06 a.m.
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
12:28 p.m.
Hi,
On Sunday, January 4, 2015, Antoine Girard <antoine(a)team51.nl> wrote:
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...
Maybe the name of that elephant is JASPIC ;)
Take a look at
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
It's an authentication module that integrates fully with container
security, and can be registered either from within the app (as the sample
in the link above demonstrates) or more traditionally at the container
level.
Undertow has really good support for JASPIC and the default stateless mode
makes it ideal to be used with JAX-RS.
Kind regards,
Arjan Tijms
What do you think about that approach?
Thank you all in advance.
Best regards,
Antoine
7:25 p.m.
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(a)team51.nl>
To: resteasy-developers(a)lists.sourceforge.net, undertow-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
4:40 a.m.
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(a)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(a)team51.nl>
> To: resteasy-developers(a)lists.sourceforge.net,
undertow-dev(a)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(a)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
3432
days inactive
3434
days old
3 comments
3 participants
participants (3)
-
Antoine Girard -
arjan tijms -
Stuart Douglas