Hi Django.
Why do you use Grizzly container? And why you don’t use Servlet container? Basic and digest auth is implemented out-of-the-boc. In web.xml you can manage secured context easily…
Back to Grizzly. What Grizzly container module you chose? Do you use GrizzlyHttpServerFactory or GrizzlyWebContainerFactory?
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]. The WebComponent is used with common servlet deployment and it is also used by GrizzlyWebContainerFactory. But I have no idea how to secure Grizzly Servlet container [3]. That’s the place Alexey could help. And as you can see [4] using GrizzlyHttpServerFactory the isUserInRole is not currently supported (always returns false). Not sure if possible to get security information from org.glassfish.grizzly.http.server.Request instance - this is the object GrizzlyHttpContainer.getSecurityContext works with. This could be also question for Alexey. ;-)
Best regards,
-lk
[1]
https://github.com/jersey/jersey/blob/e3d0c1b14eccf108262279f3f15ffbe8514a322d/core-server/src/main/java/org/glassfish/jersey/server/filter/RolesAllowedDynamicFeature.java#L132
[2]
https://github.com/jersey/jersey/blob/f77553a686039f694a0c2e73b9ae1bbe2d5527ae/containers/jersey-servlet-core/src/main/java/org/glassfish/jersey/servlet/WebComponent.java#L411
[3]
https://github.com/jersey/jersey/blob/1b9b0772e15fe2378c1b68705dd6146f75e5d6b3/containers/grizzly2-servlet/src/main/java/org/glassfish/jersey/grizzly2/servlet/GrizzlyWebContainerFactory.java#L244
[4]
https://github.com/jersey/jersey/blob/d03b4d05c3d2bf7ffb8a863f6822eeee1ac3e071/containers/grizzly2-http/src/main/java/org/glassfish/jersey/grizzly2/httpserver/GrizzlyHttpContainer.java#L408
On 08 Aug 2014, at 06:28, Django <django013_at_soft.schwarzrot-design.de> wrote:
> Hello,
>
> On Friday 08 August 2014 - 00:19:57, Oleksiy Stashok wrote:
>> in Grizzly there is no out-of-the-box support for digest authentication,
>> but it's possible for write it using Grizzly Filters API... still I'm
>> not sure how it supposed to work along with Jersey annotations (if it's
>> needed).
>
> I'm pretty new to jersey and grizzly, so I don't know, where the cut of
> responsibility is.
>
> From my little POC I would suppose, that grizzly handles all socket related
> stuff, whereas jersey comes into play for request processing. But path related
> filtering could be a role of both frameworks ...
>
> As authorization requires intermediate responses/requests, responsibility is
> not clear at first sight ...
>
>> If you chose to implement this using Grizzly Filters - please let me
>> know, I'll try to provide you more information.
>
> Yes please.
>
> Currently the resource is bound neither to jersey nor to grizzly and i like
> that. The import section of the resource looks like:
>
> import javax.annotation.security.PermitAll;
> import javax.annotation.security.RolesAllowed;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.core.MediaType;
>
> So jersey is almost invisible. Pretty good :)
>
> A ContainerRequestFilter is the right place for authorization from my point of
> view, but it is not always invoked. With authorization, the import section of
> ContainerRequestFilter looks like
>
> import java.io.IOException;
> import java.security.Principal;
> import javax.ws.rs.NotAuthorizedException;
> import javax.ws.rs.container.ContainerRequestContext;
> import javax.ws.rs.container.ContainerRequestFilter;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.SecurityContext;
> import javax.ws.rs.core.UriInfo;
> import javax.ws.rs.ext.Provider;
> import org.glassfish.jersey.server.ContainerRequest;
> import org.glassfish.jersey.server.internal.process.MappableException;
>
> I'm not happy about the jersey import at this level of code but I don't want
> to have "internal" imports.
> Currently the main-class is the only class, with a grizzly related import.
> That's acceptable. If I change runtime environment, I have to replace the
> main-class only.
>
> I'd like to achieve something similar with authentication/authorization. A
> Filter that works at javax.ws.rs abstraction level would be great. A Filter
> with jersey dependencies I would consider acceptable, but a Filter with
> grizzly dependencies is possible, but if I could avoid it, I would prefer
> others.
>
> What I don't understand is the fact, that a ContainerRequestFilter will be
> triggered for non protected paths but not for protected paths. From my point
> of view, it should be triggered before resource filtering.
>
> I would appreciate it a lot, if someone could shine me a light on workflow
> conception and cut of responsibility between grizzly and jersey.
>
>
> br Django