Administration

Defining Access Control Graphs

Authorization lists are maintained in the form of W3C ACL “access control graphs” in the respective system repository of a request repository’s account. This graph is modified through standard graph store operations, whereby the account owner always retains write access to the repository, independent of its actual content. For example for the account Account1, the respository system contains the access control graph and is available as the resource

<http://dydra.com/Account1/system>

Capability lists are not managed - they are constructed dynamically as the respective entities are referenced. The only administration permitted is to clear the cached list, with a DELETE request to respective user resource

<http://dydra.com/users/User1/capabilities>

The user resource permits also a GET request, to determine the current status.

Capability Determination

The service determines the direct authorization for a specific

(agent x resource x operation)

combination by applying a SPARQL query to the accounts system repository. If that repository includes a view named direct-authorization that query is applied.

Authentication Templates / Use Cases

Authenticated User

[ acl:accessTo <http://dydra.com/Account1/Repository1> ;
  acl:mode acl:Read ;
  acl:agent <http://dydra.com/users/User1> . ]

or

[ acl:accessTo <http://dydra.com/Account1/Repository1> ;
  acl:mode acl:Read ;
  acl:agent <http://dydra.com/account/Account2> . ]

Anonymous User

Anonymous read access to a repository is declared in the respective request system repository as

[ acl:accessTo <http://dydra.com/Account1/Repository1> ;
  acl:mode acl:Read ;
  acl:agent foaf:Agent ]

Controlled View

An anonymous controlled view is declared in the respective request system repository as

[ acl:accessTo <http://dydra.com/Account1/Repository1/View1> ;
  acl:mode acl:Execute ;
  acl:agent foaf:Agent . ]
[ acl:accessTo <http://dydra.com/Account1/Repository1> ;
  acl:mode acl:Read ;
  acl:agent <http://dydra.com/Account1/Repository1/View1> . ]

Collaborators

A collaborative role for a user is declared in the respective request system repository as

[ acl:accessTo <http://dydra.com/Account1/Repository1> ;
  acl:mode acl:Read ;
  acl:agent <http://dydra.com/users/User2> . ]

Project Manager

Where a user is to exercise control over another account, the respective authenticated account must have execute access to the other account, by virtue of a membership relation. The following assertions declare this access:

in system/system

<http://dydra.com/account/project-account> rdf:type sioc:UserAccount .
<http://dydra.com/account/dev-account> rdf:type sioc:UserAccount .

in project-account/system

[ acl:accessTo <http://dydra.com/account/project-account> ;
  acl:Mode acl:Execute ;
  acl:agent ?manager . ]

in dev-account/system

<http://dydra.com/account/project-account> prov:hadMember <http://dydra.com/account/dev-account> .

The consequence is that for any operation for which the dev-account had access, the same access is to be allowed to the project account.

External Federation

Each external federation service location

For a location such as http://dbpedia.org/sparql, to permit authenticated users to execute service requests agains it, the assertion in the dbpedia.org/system repository should be

[ acl:accessTo <http://dbpedia.org/>  ;
  acl:mode acl:Read ;
  acl:agent <urn:dydra:User> . ]

Other Roles

Additional roles are to be defined.