Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(WebID / FOAF+SSL)
Line 24: Line 24:
 
Depending on the granularity, the access control mechanisms can affect performance but should not affect semantics.  
 
Depending on the granularity, the access control mechanisms can affect performance but should not affect semantics.  
  
Some approaches to access control are discussed below.
+
== Use Cases ==
  
 +
Please define here some access control use cases
 +
 +
=== Giving members of a (Working) Group (write) access to a number of resources ===
 +
 +
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 [http://www.w3.org/2005/Incubator/webid/tpac/group.n3 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 other people working for the same company". This means that access to the resource can be determined very flexibly by delegating roles to each member.
 +
 +
 +
== Technologies ==
 +
 +
Some approaches to access control are discussed below.
  
 
=== W3C WebAccessControl ===
 
=== W3C WebAccessControl ===

Revision as of 21:46, 12 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 a number of resources

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 other people working for the same company". This means that access to the resource can be determined very flexibly by delegating roles to each member.


4 Technologies

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

[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