Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(Access Control: replace entity by agent. Agents are the set of things that act.)
(a number of updates)
Line 2: Line 2:
  
 
Earlier thinking about Access Control has been moved to [https://www.w3.org/2012/ldp/wiki/OldAccessControlPage Old Access Control Page].
 
Earlier thinking about Access Control has been moved to [https://www.w3.org/2012/ldp/wiki/OldAccessControlPage Old Access Control Page].
 
  
 
== Access Control ==
 
== Access Control ==
  
Access Control is a mechanism through which permissions are granted (or denied) to agents --  
+
Access Control is a mechanism through which an agent ( an http server in this case ) permits other agents --  
individuals, organizations, and/or groups made up of these -- to perform operations on resources. Within this document, the resources are
+
individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as specified by a policy for that resource.  
LDP resources, but the access control may operate at different granularities: RDF or other documents, named graphs, individual triples, or individual attributes.   
+
Within this document, the resources are LDP resources, but the access control may operate at different granularities: RDF or other  
The operations are create, read, update, and delete (CRUD).
+
documents, named graphs, individual triples, or individual attributes.  The operations are create, read, update, and delete (CRUD).
  
When an entity requests a collection of resources it gets to see only those resources or parts of resources it is authorized for.
+
When an agent requests a collection of resources it gets to see only those resources or parts of resources it is authorized for.
  
 
Depending on the granularity, the access control mechanisms may affect performance, but should not affect semantics.
 
Depending on the granularity, the access control mechanisms may affect performance, but should not affect semantics.
Line 28: Line 27:
 
# to READ, UPDATE, CREATE or DELETE, PATCH a resource identified by a URL.  The server allows or denies the request as specified the by the ACG for the resource or request that he authenticate to do it.
 
# to READ, UPDATE, CREATE or DELETE, PATCH a resource identified by a URL.  The server allows or denies the request as specified the by the ACG for the resource or request that he authenticate to do it.
 
# to 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.
 
# to 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.
 +
# If he is denied access, he would like an explanation for why all or part of his request was denied ( so that it becomes possible to detect errors )
 +
# Adam would ideally like to know before accessing a resource if he will be able to perform an action - ie: he may have to authenticate first with one of his identities to be able to do something
  
 
=== Editability of Access Control Rules using HTTP ===
 
=== Editability of Access Control Rules using HTTP ===
Line 36: Line 37:
 
# Employees with job titles VP or SVP can sign (update) supplier contracts.
 
# Employees with job titles VP or SVP can sign (update) supplier contracts.
 
# Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the people who attended the conference.
 
# Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the people who attended the conference.
# David was denied access to some of the resources or parts of resources he requested.  He would like an explanation for why all or part of his request was denied.
 
  
 
=== User Interface Scenarios ===
 
=== User Interface Scenarios ===
Line 50: Line 50:
 
== Requirements ==
 
== Requirements ==
  
* User must be able to authenticate herself to a server with an identifier. ( All use cases )
+
* An Agent must be able to authenticate herself to a server with an identifier or as the owner of a token ( All use cases )
* Ability to create a collection of agents, identifying agents with URIs or URI patterns -- (Usecase 3.2.2, 3.2.3, 3.2.4)
+
* Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description -- (Usecase 3.2.2, 3.2.3, 3.2.4)
* Ability to create a collection of resource names -- URIs or URI patterns -- with a specified access policy. (Usecase 3.2.1.1, 3.2.3)
+
* Ability to specify a collection of resources -- identified by URIs or URI patterns, or by description -- with a specified access policy. (Usecase 3.2.1.1, 3.2.3)
* Ability to connect a collection of userIds with a collection of resource names with given access privileges. ( All use cases )
+
* Ability to connect a collection of agents with a collection of resources with given access privileges. ( All use cases )
  
 
The above three requirements require the ability, by an authorized agent to CREATE, EDIT, UPDATE relevant ACGs.
 
The above three requirements require the ability, by an authorized agent to CREATE, EDIT, UPDATE relevant ACGs.
 
* Ability to specify access privileges at a fine-grained level. (Usecase 2.2)
 
* Ability to specify access privileges at a fine-grained level. (Usecase 2.2)
 
+
* from the server to describe access control policies for a resource (Usecase 3.3)
The above requirement requires the ability, 
+
* from a server to potentially describe reasons for access being disallowed in a machine readable format
* by an authorized agent to CREATE, EDIT, UPDATE relevant ACGs at a fine-grained level.
+
* for a user-agent to be able to find the ACG for a given resource
* from the server to explain access control policies. (Usecases 3.3)
+
* for a user to query the ACGs that apply to her
+
  
 
== Outline of a Charter for a Access Control WG ==
 
== Outline of a Charter for a Access Control WG ==
Line 69: Line 67:
 
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 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 define whether to define access control at a resource or document level or whether it wants to define fine-grained access control at an attribute level.
+
The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.
  
 
=== Deliverables ===
 
=== Deliverables ===

Revision as of 08:59, 14 May 2014

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 ( 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 a policy for that resource. Within this document, the resources are LDP resources, but the access control may operate at different granularities: RDF or other documents, named graphs, individual triples, or individual attributes. The operations are create, read, update, and delete (CRUD).

When an agent requests a collection of resources it gets to see only those resources or parts of resources it is authorized for.

Depending on the granularity, the access control mechanisms may affect performance, but should not affect semantics.

For access control to come into play, the server must restrict some operations on some resources.

2 Vocabulary

  • ACG: An Access Control Graph describes which agents can have some mode of access to a resource, or collection of resources.
  • ACG Resource: A resource whose representation contains one or more ACGs and which the server relies upon to make its access control decisions.

3 Usecases

3.1 Access Control on HTTP manipulation of resources

Adam's user agent attempts

  1. to READ, UPDATE, CREATE or DELETE, PATCH a resource identified by a URL. The server allows or denies the request as specified the by the ACG for the resource or request that he authenticate to do it.
  2. to 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.
  3. If he is denied access, he would like an explanation for why all or part of his request was denied ( so that it becomes possible to detect errors )
  4. Adam would ideally like to know before accessing a resource if he will be able to perform an action - ie: he may have to authenticate first with one of his identities to be able to do something

3.2 Editability of Access Control Rules using HTTP

  1. Bart's user agent logs on to a server and requests:
    1. the ability to read a group of related resources such as all the papers presented at a conference.
    2. 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
    1. allowing friends of his to access a document
    2. allowing friends of his to POST to a container, but not read the contents of the container
    3. allow all the members of the LDP WG to create and edit resources in an LDPC

4 Requirements

  • An Agent must be able to authenticate herself to a server with an identifier or as the owner of a token ( All use cases )
  • Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description -- (Usecase 3.2.2, 3.2.3, 3.2.4)
  • Ability to specify a collection of resources -- identified by URIs or URI patterns, or by description -- with a specified access policy. (Usecase 3.2.1.1, 3.2.3)
  • Ability to connect a collection of agents with a collection of resources with given access privileges. ( All use cases )

The above three requirements require the ability, by an authorized agent to CREATE, EDIT, UPDATE relevant ACGs.

  • Ability to specify access privileges at a fine-grained level. (Usecase 2.2)
  • from the server to describe access control policies for a resource (Usecase 3.3)
  • from a server to potentially describe reasons for access being disallowed in a machine readable format
  • 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

Define the collections that are part of the ACG and define how a collection of agents is connected to a connection of resources.

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.