Thanks!
On Fri, Mar 21, 2014 at 2:08 AM, Miroslav Fuksa
<miroslav.fuksa_at_oracle.com>wrote:
> 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:
>
>
> 1. Setup an annotation for @ApiAuth or @UserAuth that I can use to
> annotate resource request methods.
> 2. 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.
> 3. 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.
> 4. 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!
>
>
>
>
>