Authorization

Introduction

Authorization should happen after authentication to define what an
authenticated user is effectively authorized to do in your application.
We identified four approaches to authorization in a Restlet application.
When we mentionned LDAP as a permission store, it could be replaced by a
static file or by any sort of database.

Coarse-grained authorization

You configure some Authorizer instances (or subclasses like
RoleAuthorizer, MethodAuthorizer, etc.) and attach them at key points in
the call routing graph (before a Router, for a single route, etc.).

This works nicely if you can assign roles to your authenticated users
and if your authorization rules don't vary too much between resources.
Otherwise, you might end-up with an Authorizer instance in front of each
resource class...

Here is a simple example, you will get a String response containing the
resource's name when accessing resources with authorized profile and
a "403 Forbidden" error otherwise.

This code is self-sufficient so you just need to copy-paste it in a
MyApiWithRoleAuthorization class, create the resources as shown below
and run it. Don't forget to add the JSE edition org.restlet.jar
(download here)
in your build path.

Fine-grained authorization

If your authorization rules tend to be very specific to each resource
class, or more complexly specific to resource instances, then it is
better to handle them at the resource level manually. As an help, you
can leverage the ServerResource#isInRole() method.

Middle-grained authorization

The idea would be to define several URI subspaces in your overall
application URI space. Each subspace would have a unique name, like a
role name. Then in LDAP you could assign permissions to roles for each
subspace, not duplicating URI information in LDAP.

Then, in your Restlet application, you could have a SubspaceAuthorizer
class that would retrieve the rules from LDAP based on a given subspace
name. An instance of SubspaceAuthorizer for each identified subspace
should be created and attached to the proper place in the routing graph.

Therefore you wouldn't need to duplicate URI matching code or have to
maintain URI templates in several places.