AccessControl

From Linked Data Platform
Revision as of 14:45, 7 July 2014 by Amalhotr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

THE CONTENTS OF THIS WIKI HAVE BEEN MOVED IN HTML FORM TO MERCURIAL IN PREPARATION FOR PUBLICATION. PLEASE DO NOT EDIT THIS WIKI.

This page includes content for a note on Use Cases and Requirements for Access Control to be produced by the Linked Data Platform WG. It also outlines a charter for developing a standard for HTTP-based access control. The work discussed in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.

Earlier thinking about Access Control has been moved to Old Access Control Page.

1 Access Control

Access Control is a mechanism through which an Agent (typically an HTTP server, in this case) permits other Agents -- individuals, organizations, and/or groups made up of these -- to perform certain Operations on Resources as specified by an Access Control Graph for that Resource. Such an Access Control Graph might be the result of evaluating an Access Control Policy, but that is optional.

Within this document, Resources are LDP Resources, but the Access Control may operate at different granularities: entire RDF or other documents, named graphs, individual triples, or individual attributes. The Operations under discussion are Create, Read, Update, and Delete (CRUD).

When an Agent requests a collection of Resources, it is shown only those Resources (or parts of Resources) for which it has Read permissions.

High granularity Access Control may affect performance, but semantics should never be impacted by Access Control.

For Access Control to come into play, the server must restrict some operations on some Resources.

2 Vocabulary

  • ACG: An Access Control Graph describing which Agents are permitted (or forbidden) some Operations upon a Resource or collection of Resources.
  • ACG Resource: A Resource whose representation contains one or more ACGs and upon which the server relies to make its Access Control decisions.

3 Use Cases

3.1 Access Control on Manipulation of Resources via HTTP

  1. Adam's user Agent attempts to
    • CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately allow or deny the request, or it may request that he authenticate to confirm his privileges, as specified the by the ACG for the Resource.
    • UPDATE, CREATE or DELETE an attribute of the resource identified by the URL. The server allows or denies the request as specified the by the ACG for the resource and attribute and whether fine-grained access control is supported.
  2. If he is denied access, an explanation of why all or part of his request was denied should be provided (so that it becomes possible to detect errors, and so that he may modify the request -- potentially to include making a request for such privileges).
  3. Adam would ideally like to know whether he will be able to perform an Action on a Resource before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.

3.2 Editing of Access Control Rules using HTTP

  1. Bart's user Agent logs on to a server and requests:
    • the ability to read a group of related resources such as all the papers presented at a conference.
    • the ability to update an attribute of related resources, for example, to add a copyright notice to each resource.
  2. Employees with job titles VP or SVP can sign (update) supplier contracts.
  3. Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the people who attended the conference.

3.3 User Interface Scenarios

Eddie's HTTP based user agent would like to provide a user interface to allow where possible Eddie to

  1. know if he can edit or delete a resource
  2. know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have paid a fee )
  3. allow Eddie to edit the access control rules for a resource such as
    • allowing friends of his to access a document
    • allowing friends of his to POST notifications to a container, but only read a subset of the contents of the container, those posted by that agent for example
    • allowing all the members of the LDP WG to create and edit resources ( including LDPCs ) under a specific URL pattern
    • allowing all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments to a container related to some content, and edit their own comments
    • allowing the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, found on the web, onto the User Interface as a way of creating the union of the members of the group.

4 Requirements

  1. An Agent must be able to authenticate herself to a server with an identifier or as the owner of a token (All use cases )
  2. Ability of an authorized agent to CREATE, EDIT, UPDATE relevant ACGs, enabling:
    1. Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description -- (Use case 3.2, 3.2, 3.2)
    2. Ability to specify a collection of resources -- identified by URIs or URI patterns, or by description -- with a specified access policy. (Use case 3.2, 3.2)
    3. Ability to connect a collection of agents with a collection of resources with given access privileges. (All use cases)
  3. Ability to specify access privileges at a fine-grained level. (Usecase 3.2)
  4. Ability for a server to describe access control policies for a resource (Usecase 3.3)
  5. Ability for a server to potentially describe reasons for access being disallowed in a machine readable format
  6. Ability for a user-agent to be able to find the ACG for a given resource

5 Outline of a Charter for a Access Control WG

An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of resources. It then connects a collection of agents with a collection of resources with the connection identifying the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.

The members of the collection of agents contain tokens that the agents obtain from some authentication service. The members of the collection of resources are URIs or URI templates.

The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.

5.1 Deliverables

  1. Define the collections that are part of the ACG and define how a collection of agents is connected to a connection of resources.
  2. Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed efficiently with the ACG structure defined above.