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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Libor Kramolis
Hi Django.

I’m involving Grizzly user group because I’m convinced it is necessary to setup digest authentication using Grizzly API.

-libor


On 07 Aug 2014, at 15:58, Django <[hidden email]> wrote:

> Hi Libor,
>
> thank you for your attention.
>
> On Thursday 07 August 2014 - 14:23:29, Libor Kramolis wrote:
>> The functionality depends on container. Jersey servlet/application must be
>> secured by container, e.g. security-constraint and login-config web.xml
>
> well, I don't want to do configuration by xml-coding
>
>> ... Jersey then delegates security checks to appropriate container. Try to
>> find out how to secure grizzly server similar way as servlet.
>
> Referring to the jersey sample "https-clientserver-grizzly" - that's the way,
> I'd like to setup my service.
>
> I did not find a working sample using digest authentication. May be I got
> things wrong. Jersey userguide states (5.9.1): Jersey supports Basic and
> Digest Http authentication.
>
> I wonder, how that support looks like?
>
> When I look at AuthenticationExceptionMapper it looks like I have to code the
> Authentication header myself. That's no problem, but if there's any support
> for authentication in jersey, I would like to use it.
>
> The @RolesAllowed annotation looks like resource filtering to me, but not as
> authorization support. So what's the right way to get into play when such a
> resource will be requested without authentication header?
>
> Is it possible to mix @RolesAllowed with ContainerRequestFilter?
>
> The other way would be, extend each resource method with @Context HttpHeaders
> and do all restrictions myself? Does it mean, I may not use @RolesAllowed
> annotations?
>
>
> br Django

Reply | Threaded
Open this post in threaded view
|

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

oleksiys
Administrator
Hi,

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).

If you chose to implement this using Grizzly Filters - please let me
know, I'll try to provide you more information.

Thanks.

WBR,
Alexey.

On 07.08.14 14:04, Libor Kramolis wrote:

> Hi Django.
>
> I’m involving Grizzly user group because I’m convinced it is necessary to setup digest authentication using Grizzly API.
>
> -libor
>
>
> On 07 Aug 2014, at 15:58, Django <[hidden email]> wrote:
>
>> Hi Libor,
>>
>> thank you for your attention.
>>
>> On Thursday 07 August 2014 - 14:23:29, Libor Kramolis wrote:
>>> The functionality depends on container. Jersey servlet/application must be
>>> secured by container, e.g. security-constraint and login-config web.xml
>> well, I don't want to do configuration by xml-coding
>>
>>> ... Jersey then delegates security checks to appropriate container. Try to
>>> find out how to secure grizzly server similar way as servlet.
>> Referring to the jersey sample "https-clientserver-grizzly" - that's the way,
>> I'd like to setup my service.
>>
>> I did not find a working sample using digest authentication. May be I got
>> things wrong. Jersey userguide states (5.9.1): Jersey supports Basic and
>> Digest Http authentication.
>>
>> I wonder, how that support looks like?
>>
>> When I look at AuthenticationExceptionMapper it looks like I have to code the
>> Authentication header myself. That's no problem, but if there's any support
>> for authentication in jersey, I would like to use it.
>>
>> The @RolesAllowed annotation looks like resource filtering to me, but not as
>> authorization support. So what's the right way to get into play when such a
>> resource will be requested without authentication header?
>>
>> Is it possible to mix @RolesAllowed with ContainerRequestFilter?
>>
>> The other way would be, extend each resource method with @Context HttpHeaders
>> and do all restrictions myself? Does it mean, I may not use @RolesAllowed
>> annotations?
>>
>>
>> br Django

Reply | Threaded
Open this post in threaded view
|

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

Django
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
Reply | Threaded
Open this post in threaded view
|

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

Libor Kramolis
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


On 08 Aug 2014, at 06:28, Django <[hidden email]> 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