users@jersey.java.net

[Jersey] Re: Is there a Basic Auth server example?

From: Miroslav Fuksa <miroslav.fuksa_at_oracle.com>
Date: Fri, 21 Mar 2014 10:08:16 +0100

Hi,

we currently don’t have basic authentication support for the server side (we support only the client via HttpAuthorizationFeature). On the server side we expect the authentication is done by the container. Once the authentication done (by servlet container) then you can use annotations like @javax.annotations.RolesAllowed to annotate resources and Jersey will perform authorization mechanism for you. I think this can replace your proposed annotations ApiAuth and UserAuth. You will define roles ‘api' and ‘user’ and then use only @RolesAllowed({“api”}). Is this suitable for your case? Of course you will need to implement the filter. You can check this filter from Jersey https grizzly example: https://github.com/jersey/jersey/blob/master/examples/https-clientserver-grizzly/src/main/java/org/glassfish/jersey/examples/httpsclientservergrizzly/SecurityFilter.java which performs such an authentication.

If you want to use security annotations, you need to register RolesAllowedDynamicFeature to enable these annotations. See https://jersey.java.net/documentation/latest/security.html#d0e10543.

Mira

 
On Mar 20, 2014, at 7:20 PM, Robert DiFalco <robert.difalco_at_gmail.com> wrote:

> I'd like to use basic auth on my J2SE/Grizzly Jersey server. I am not using J2EE security.
>
> Essentially, I just want a simple way to delegate Basic Auth checks to database lookups.
>
> Are there any examples of this? I think I know how to write it on my own but I don't want to reinvent the wheel.
>
> Without guidance I would take the following approach:
>
> Setup an annotation for @ApiAuth or @UserAuth that I can use to annotate resource request methods.
> Create a filter that takes the "authorization" header, base64 decodes the value. If the method is @ApiAuth then verify it matches my static API's API_KEY and API_SECRET.
> If it is @UserAuth ensure the value matches the user intended for the url. These usually take the form of "/user/1/some_user_resource" where 1 is the primary key of the user. So I would look up the user credentials at id 1 and ensure they match the user and password in the header.
> If either of these don't match raise a not authorized exception.
>
> That's pretty much it sans some caching and edge cases. Should I just implement this or are there Jersey provided classes I'm not aware of or a better approach to take?
>
> Thanks!
>
>
>