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

« Previous Version 4 Current »

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

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.

Publication

User

Request

Result

Curator

create Dataset "DS-1  "

DS-1   is created.

Curator

share DS-1   with FederationGroup, with READ/CHANGE/SHARE access

DS-1   is shared.

Bob (generic user)

get all Datasets

list of datasets returned, omitting DS-1  

Federation Member

share DS-1   with Public, with READ access

DS-1   is published.

Bob (generic user)

get all Datasets

list of datasets returned, including DS-1  

Separate Permissions for Meta-Data and Content

User

Request

Result

Curator

Create DS-1  

DS-1   is created.

Curator

share DS-1   with Public, READ access

DS-1   is shared.

Curator

share DS-1   with FederationGroup, DOWNLOAD access

DS-1   is shared.

anonymous

get all Datasets

list of datasets returned, including DS-1  

anonymous

download DS-1  

UnauthorizedException

Federation Member

download DS-1  

DS-1   is downloaded

Create Administrator

User

Request

Result

admin

Add Carol to group "Administrators"

Carol now has full administrative rights.

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

  • No labels