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.