Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(How to Contribute)
Line 13: Line 13:
Contributors, please include a brief description and example.
Contributors, please include a brief description and example.
Ideally, this page will provide a little orientation and analysis of the resources in [http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/ Chris Bizer's Semantic Web Trust and Security Resource Guide]
Ideally, this page will provide a little orientation and analysis of the resources in [http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/ Chris Bizer's Semantic Web Trust and Security Resource Guide] ( no longer updated )
== Access Control ==
== Access Control ==

Revision as of 09:30, 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 ( no longer updated )

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 responsibility of group membership to each member ( using linked data ). Editing such groups could then itself be done with LDP.

3.2 Giving access to open sets of resources

It should be possible to specify efficiently that large sets of resources (existing or not) are accessible to given agents. ( eg. by using POWDER to specify regexpressions on resources )

3.3 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 to that collection and as a result create an new collection of type sioc:Account. That user should then be able to set the access control rules for the collection he created and indeed for individual resources.

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

3.5 Clearer Error reporting on access denial

A standard way to be more precise on refusals would be very useful to help debug systems and make user interactions on access control systems friendly and debuggable. 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 for a certain action
    • Network problem? ( could not access ACL )
    • Access error: server could not access the ACL to determine the authorization ( due to ACL restrictions on the ACL)
    • Logic problem: Server does not understand the vocabulary of the 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:hasAccessCondition :ac1.
   :ac1 a s4ac:AccessCondition;
        """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

WebID spec, defined at the WebID Incubator/Community group, is an efficient way using TLS and public key cryptography to identify a user by a URI which can itself be a Linked Data Resource, and so can be managed by LDP. TLS makes it easy to add protection per resource without requiring a resource to be tied to any further authentication end point, and allows for good error reporting ( when enhanced with semantic descriptions ). Attribute Exchange about the user can be done using LDP too.

5.2 OpenID

OpenID authentication also allows one to tie an identity to a resource that could be an LDP resource, though usually it is aimed at end users with little technical experience in order to help them log in to remote sites by tying their identity to their blog page. Attribute exchange is done with its own protocol rather than by using an Linked Data system. It also requires a lot of connections to authentify a user successfully, as shown by the OpenId sequence diagram.

5.3 BrowserID

BrowserID authentifies an e-mail address using cryptographic keys. It could work together with a WebID URL too as explained by the StackExchange WebID/BrowserID comparison. It requires javascript to be executed by the client - making it less efficient and prone to denial of service attacks as opposed to TLS client authentication.