[Jersey] Re: looking for helping hand on securing service

From: Django <>
Date: Fri, 8 Aug 2014 17:40:45 +0200


> Why do you use Grizzly container? And why you don’t use Servlet container?

I want a small footprint service. My first thought was about HttpComponents,
but then I read about jersey ...

I hate maven and lots of stuff, jersey brings into play, ...
... but my way to learn a library or framework is doing things the way the
developers recommend it to do (and I hope, I can strip most of the dead
freight later)

grizzly looked to me to be the smallest server part. But maven bloated my
harddisk anyway :(
Each sample results in tons of downloads - its awful :O

> Back to Grizzly. What Grizzly container module you chose? Do you use
> GrizzlyHttpServerFactory or GrizzlyWebContainerFactory?

I followed the sample from userguide chapter 1.1 (creating a project with

> You can see RolesAllowedDynamicFeature uses
> requestContext.getSecurityContext().isUserInRole(role) [1] to implement
> security filtering. It means the functionality is depending on
> implementation of isUserInRole method implementation.
> ...
> Servlet delegates to HttpServletRequest.isUserInRole, see class
> WebComponent [2].

GREAT! Thanks a lot for the links!

Internal ContainerRequestFilter of RolesAllowedDynmaicFeature looks good.

The problem is the private call WebComponent.getSecurityContext which creates
a SecurityContext bound to the request, but that request should change ...

The question is: who is responsible to throw an NotAuthorizedException?
From my point of view, the SecurityContext should get that responsibility.
HttpServletRequest.isUserInRole() would be the wrong place.

So the SecurityContext should first determine, whether the resource is
restricted and if so, if the request contains an authentication header.
Therefor the default implementation of the SecurityContext created by
WebComponent.getSecurityContext() is to trivial and does not fit.

A NotAuthorizedException should then be translated to a HttpResponse with
status 401 and an authentication header matching the authentication scheme
Jersey sample "https-clientserver-grizzly" introduced an
AuthenticationExceptionMapper, which sounds promising.

HttpComponents-core uses different classes for each header type. That's nasty
and an easy way to hide the grunt part of authorization calculations ;)

The current implementation of WebComponent.SecurityContext could continue as a
default implementation, but then there should be a way for jersey users to
inject a SecurityContextFactory or the like ...

best regards