Difference between revisions of "AccessControl"

From Linked Data Platform
Jump to: navigation, search
(+ requirements table)
Line 76: Line 76:
== Requirements (based on Use Cases) ==
== Requirements (based on Use Cases) ==
* Access Control Vocabularies
* <span id="vocab">Access Control Vocabularies</span>
* Agent Identification
* Agent Identification
* Resource Identification
* Resource Identification
* ...
* ...
== Candidate Technologies to satisfy Requirements ==
== Candidate Technologies to satisfy Requirements ==

Revision as of 13:50, 14 March 2013

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 present 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
    • ...

3.6 Creating a new resource with ACL restrictions

A bug database exists for some product. A user wishes to create a new bug report on a security issue ( by POSTing it to a collection ) but wants to make sure it has limited visibility to give the software vendor time to fix it. The Bug reports are normally publicly readable. If paranoid enough it seems that doing this in two steps may be too slow: creating the resource and then later changing the access control rule. So there is a case that this needs to be done at resource creation time.

3.7 LDP and Authentication/Authorization

Access to the Linked Data Platform often may require authentication and authorization. Access by clients can depend on the interaction context (different resources are needed for accomplishing different goals), client identity (different clients have different levels of access), and possibly client roles (access control may be coupled to roles instead of identities, in which case client/role associations need to be established) and/or client attributes (access control may be coupled to attributes which can be used even when the client identities are unknown, assuming that the attributes can be reliably determined). On the Web, many different ways of identification (establishing naming schemes that uniquely identify entities of interest), authentication (frameworks for verifying someone's claim to have an identity), and authorization (granting access to a resource based on an identity and some access control scheme) exist. In addition, in many cases platforms must integrate into existing scenarios around these issues, and cannot freely pick a framework from scratch. Thus, LDP should provide developers with some guidance around the following issues:

  • How should LDP services integrate into existing landscapes of identification, authentication, and authorization? For some established technologies, maybe we can provide guidance and patterns on how to support them.
  • What is a reasonable authentication and authorization model? LDP will be used to drive many different services, and these might have different models of how clients should have access to LDP services in the context of those specific application scenarios. What is a reasonable model so that LDP providers can handle this flexibility, and still can support identification, authentication, and authorization frameworks that are dictated by the environment? In this context, is it more reasonable to deal with roles or attributes in granting the access to the clients?

4 Requirements (based on Use Cases)

  • Access Control Vocabularies
  • Agent Identification
  • Resource Identification
  • ...

5 Candidate Technologies to satisfy Requirements

5.1 Access Control Vocabularies

Some approaches to access control are discussed below.

5.1.1 W3C WebAccessControl

Grant Read|Write|Append|Control permissions for a principle identified by a URL to access another URL. 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.

5.1.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".}""".

5.1.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.2 Agent Identification

Below are some well known identity systems. These are well known ways of tying a user to a string, known as a Principal. These are not incompatible as shown in the Identity Interoperability wiki page.

5.2.1 HTTP Basic or Digest

RFC 2617 defines HTTP Basic and Digest authentication mechanisms.

5.2.2 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.3 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.2.4 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.