Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(Shi3ld)
(Shi3ld)
Line 69: Line 69:
 
     s4ac:hasAccessCondition :ac1.
 
     s4ac:hasAccessCondition :ac1.
 
    
 
    
:ac1 a s4ac:AccessCondition;
+
  :ac1 a s4ac:AccessCondition;
 
     s4ac:hasQueryAsk
 
     s4ac:hasQueryAsk
 
    """ASK {?context
 
    """ASK {?context

Revision as of 14:12, 9 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 below.

Some approaches to access control are discussed below.


2.1 W3C WebAccessControl

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

2.1.1 Examples

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


2.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).

The policy below (: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".}""".

2.3 Oracle Triple-based Access Control

3 Identity

3.1 WebID / FOAF+SSL