On Wed, May 14, 2014 at 4:46 AM, Sergio <sertin...@gmail.com> wrote:

> Can I attach the authenticator to only some of the methods of my
> resources? I.e. protect only PUT, POST, and DELETE while keeping GET
> public? Maybe using roles?

You can do per-resource or even per-method authorization: Remember that
authentication and authorization are separate steps, and that you can make
authentication optional. You can attach an authenticator at an outer level
and then in specific methods you can examine the authenticated user (if
any) and its roles to determine whether to allow or forbid a method.

The authenticated user can be obtained via getClientInfo().getUser().

You can even combine these approaches:

  Authenticator -> Authorizer -> ... -> Resource method ->
per-resource/method authorization

This might be useful, for example, if you have a common level of
authorization for a group of resources, but you have specific additional
authorization requirements on certain resources.

> If not, I'm thinking about splitting my services in two families of
> resources /apps/ which will implement authentication and /info which will
> be public. Do you think it is a good solution?

It depends on whether your resources naturally decompose into mutable and
read-only resources. If they do, that's probably preferable.

In my work I confine resource-specific authorization to a few places where
it is much more natural to say something like "You must have the ADMIN role
to PUT this resource, but anyone can GET it" than to break things up into
separate resources. Most of the time, though, I try to keep read-only
resources under separate paths in my routing structure.



Reply via email to