Skip to end of banner
Go to start of banner

Authorization - Functional Specification

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

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.

User 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.

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.

User Group 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

User

Request

Result

anonymous

get all Datasets

the list of Datasets to which the Public has READ access

Resource Creation

User

Request

Result

Alice (non-admin)

create group "MyGroup"

MyGroup is created.

Alice (non-admin)

create Dataset "DS-1"

UnauthorizedException

admin

create group "Curators"

Curators is created.

admin

add Dataset creation authority to Curators

Curators is updated.

admin

add Alice to Curators

Curators is updated.

Alice

create Dataset "DS-1"

DS-1 is created.

Create Administrator

User

Request

Result

admin

Add Bob to group "Administrators"

Bob now has full administrative rights.

  • No labels