Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(Finding out access control policies for a resource)
(Technologies)
Line 52: Line 52:
 
** Network problem? ( could not access ACL )
 
** Network problem? ( could not access ACL )
  
== Technologies ==
+
== Access Control Vocabularies ==
  
 
Some approaches to access control are discussed below.
 
Some approaches to access control are discussed below.

Revision as of 08:54, 13 November 2012

This page collects content for a future Note on Use Cases and Requirements for Access Control to be produced by the Linked Data Platform WG. The LDP Charter states:


The Working Group will not produce a Recommendation specifying solutions for access control and authentication for Linked Data. However the Working Group may identify, based on a set of real world use cases, requirements for authentication and authorization technologies for use with Linked Data.

Deliverable, Not Recommendation Track: Access Control: Working Group Note on Use Cases and Requirements for access control and authentication mechanisms needed for this work.


1 How to Contribute

Contributors, please include a brief description and example. Ideally, this page will provide a little orientation and analysis of the resources in Chris Bizer's Semantic Web Trust and Security Resource Guide

2 Access Control

Access Control is a mechanism to enable or deny permissions to entities - individuals, groups of individuals or organizations - to perform operations on resources. In the case of LDP the resources are LDP resources but the access control may operate at different granularities: RDF documents, named graphs or individual triples. The operations are read, update, create and delete.

Entities need to be identified. See section on Identity below.

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

3 Use Cases

Please define here some access control use cases

3.1 Giving members of a (Working) Group (write) access to collections

When working with linked data one may need to give members of some group of individuals/robots write access to resources such as the ability to POST to a collection their preferred meeting time for an event. An example of such a group could be given by a linked data resource such as the foaf:Group of people who attended the TPAC webid/rww/social-web meetup. The group could be specified more generally even as "members of the group, and their direct colleagues". This means that access to the resource can be determined very flexibly by delegating roles to each member, by using linked data to determing group membership. Editing such groups could then itself be done with LDP.

3.2 Setting Access Control Policies for a Resource or set of resources

It should be easy to use LDP to set access control policies for a resource or collection of resources. One could imagine for example a server that has a collection for creating user accounts. Anybody on the internet - or some subset perhaps -could POST an account to that collection. That user should then be able to set the access control rules for the collection he created and indeed for individual resources.

3.3 Finding out access control policies for a resource

Some agents A wants access to a resource ( HTTP GET will do ), but is not allowed access. In some cases ( very high security systems in some circumstances ) nothing more should be said. But in most everyday scenarios it is very important to prent the agent A some reasonable explanation for why he did not get access. A link from the requested resource to the access control policy would be very helpful. Perhaps A can find out that the particular resource is only visible to friends of some of the resource owners friends - in which case the requestor would know that by becoming friends with someone he could get access to the resource. Another resource may allow access to members of a group, which only those members can see the members of. That would at least allow members of the group to know if there was a bug in the server that denied them access. Without such information access control bugs would be impossible to debug.

Perhaps a 401 or 403 should also return some machine readable information on what the error was so that the client can distinguish clearly between different issues such as

  • Authentication problem?
    • Could not verify one of user's principals ( some type of identifier the user has)
    • Network problem in verification step
  • Authorization problem?
    • User is not authorized
    • Network problem? ( could not access ACL )

4 Access Control Vocabularies

Some approaches to access control are discussed below.

4.1 W3C WebAccessControl

Grant Read|Write|Append|Control permissions for a principle identified by a URL to access another URL.

4.1.1 Examples

@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

[acl:accessTo <card.rdf>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card.rdf>; acl:mode acl:Read, acl:Write;  acl:agent <card#i>].

This means that anyone may read card.rdf, and <card#i> can write it.


[acl:accessTo <card.rdf>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card.rdf>; acl:mode acl:Write;  acl:agent <card#i>].

Because acl:agent has domain foaf:Agent the last line implies that <card#i> is a foaf:Agent.

4.2 Shi3ld

Shi3ld is an attribute-based authorization framework to protect RDF named graphs. Access Policies are defined using Semantic Web languages only (RDF and SPARQL).

In the example below, the policy :policy1 protects the named graph :ng1 from read access (i.e., SPARQL SELECT, CONSTRUCT and ASK queries). The policy contains a set of Access Conditions (:acs1) that includes the access condition :ac1. The latter allows access only if the user is located in a point of interest (POI) at given geo coordinates, with a radius of 500m.

   :policy1 a s4ac:AccessPolicy;
     4ac:appliesTo :ng1;
     s4ac:hasAccessPrivilege [a s4ac:Read];
     s4ac:hasAccessConditionSet :acs1.

   :acs1 a s4ac:AccessConditionSet;
     s4ac:ConjunctiveAccessConditionSet;
     s4ac:hasAccessCondition :ac1.
   
   :ac1 a s4ac:AccessCondition;
      s4ac:hasQueryAsk
        """ASK {
                 ?context a prissma:Context;
                     prissma:environment ?env.
                 ?env prissma:currentPOI ?poi.
                 ?poi prissma:radius "500";
                      foaf:based_near ?p.
                 ?p  geo:lat "43.615811";   
                     geo:long "7.068532".}""".

4.3 Oracle Triple-based Access Control

The Oracle RDF store, which is based on the Oracle Relational database, offers two granularities of access control: Model-based access control, based on a database view, allows access control through Grant/Revoke operations on the view, and triple-level access control through Oracle label security.

To enable triple-level security, triples and users are tagged with security labels. Labels determine the sensitivity of the data or the rights a person must posses in order to read or write the data. If the user’s read label dominates the triple's read label, the user can access the triple. If the user’s write label dominates the triple's write label, the user can update the triple. A Security Administrator assigns labels to users.

If the user writes a SPARQL query against the data, only the triples she is allowed to read are returned. Label information is hidden from the user.

5 Identity

5.1 WebID / FOAF+SSL