Authorization in the Repository Service

Resources, Users and Groups

Requests to the repository service (RS) involve creating, retrieving, changing, deleting or sharing resources.

Each resource has a type (e.g. Dataset or Layer) and an ID unique to its type.

Requests are either made anonymously or as an authenticated user.  User IDs are unique and there is a reserved ID “admin”.

The RS supports user groups.  Each user group has (1) a set of users (2) a set of <resource, access-type> pairs, and (3) a set of resource types which the group members may create.  Access-types are open ended, but include

                READ – permission to retrieve the resource contents from RS

                CHANGE – permission to modify (update or delete) the resource

                SHARE – permission to add or remove any kind of access to the resource to any user group.

(Other useful access types might include DOWNLOAD, REVISE or EXECUTE.)

RS has the following system generated groups:

Public – All users are implicit members of this group, i.e. all users (including anonymous users) may access resources added to this group, with the specified access-type.

Administrators – Members of this group have full access to all resources.  The user “admin’ is a member of this group.

Individual Groups – Each user belongs to a group named after them, having them as the sole member, and to which they have READ access.  Access to a resource can be granted to an individual by adding the resource to their individual group.

comment:  May be useful to have a 'service' group (something like an admin group), with broad rights needed for services operating through the DAO layer.

System Behavior

Those in the administrative group have full access to all resources.

Anonymous users have just the permissions granted to Public.

A user has READ, CHANGE, and SHARE access to anything they create (provided they have permission to create such a resource).  If a resource is made anonymously then the Public has full access to the resource.

Anyone can create a new user group and add members, but such groups have no Creation rights initially.  Only those in the administrative group can provide resource Creation rights to groups.

By default group members have READ (but not CHANGE or SHARE) access to the group itself.

SHARE access is powerful, allowing a user to add or remove any type of access to the resource to/from any group.  (It should generally be limited resource creators and administrators.)  One must have SHARE access to a resource to “unshare” it (to remove access permission from a group).

By default READ access to users and user groups is public.

API

Properties of DAOs in general:

CRUD requests may through UnauthorizedException.  Query requests do not throw this exception, but omit results to which the user does not have READ access.

Additionally, each DAO has a 'hasAccess' method which, given a resource and access type, says whether the user (or Public, if anonymous) has the specified permission.

User Group DAO requests:

-          standard CRUD

-          add/remove/get all users in the group

-          add/remove/get resources in the group, given an access type

Examples

Anonymous Access

Resource Creation

Publication

Separate Permissions for Meta-Data and Content

Create Administrator

Notes / Open Questions

Should permissions be inherited by a resource's components and revisions, or should they be controlled independently?  (Or should there be a hybrid:  The permissions could be inherited initially, then subject to change.)

comment:  Keep it simple by avoid separate permissions for components.

We don't differentiate Public/anonymous from Public/logged-in, i.e. to say "anyone can access this resource, but only if they are logged in."