Access Control Graphs

Introduction

Dydra represents access controls in the form of W3C ACL graphs. Each account includes the repository system, which contains the metadata for the entities (repositories and views) which the account owns. Entries in the repository of the form

[ acl:accessTo ?entity;
  acl:accessMode ?mode;
  acl:agent ?agent. ]

constitute a direct access control list entry.

Indirect access specifications take the form of chained entries, where

• acl:Execute access accorded to an agent for one entity imputes that entity’s access permission to the agent.

• rdfs:member assertions impute the set’s access permissions to its members.

• rdf:type assertions impute the classes’s access permissions to its specializations.

The access authorization for any given primitive operation is recorded for each given request agent in the agent’s capability list as a relation among

( target resource X operation X mode )

This relation comprises the agent’s capabilities.

If no entry is present for a given ( target resource X operation ) combination, it is sought in the target’s resource access control graph (ACL). If a path is found, the true permission state is saved. Otherwise false is cached.

The search for authorization is governed by this request state.

In detail

• agent : This is an authenticated, located or anonymous agent, depending on authentication credentials. This value is derived during the authentication process and remains unchanged.

• account : This is the account for which the agent is authenticated - or none for anonymous access. This value is derived during the authentication process. If a federation operation designates a local repository as the service clause location it asserts the repository owning account for this for the duration of that sub-query.

• repository : the repository which is the target of the query. This is initially designated by the request as the HTTP request resource. A federation operation asserts the service clause location for this for the duration of that sub-query.

• view : the currently active view - or none for in-line queries. This is initially determined from the request. If the request resource designates a view, that is the initial value. Otherwise the inline content serves as an anonymous view.

• access mode : read or write, as per the request operation

The initial state comprises just the request’s agent – the user and/or account, repository and mode.

Abstract Types

The initial access control ontology comprises the following

<urn:dydra:User> rdf:type Initial Capabilities ——————–

There are two aspects to authorization: for access to the request query or view and for access to repository data. An authenticated agent’s inherent capabilities are

• execute access to all views defined in the authenticated account

• execute access to an inline view

• read, write, and execute access to all repositories owned by the authenticated account.

For any account, any respectively authenticated agent possesses as inherent capabilities:

<http://dydra.com/Account1/system> acl:Read true
<http://dydra.com/Account1/system> acl:Write true
<http://dydra.com/Account1/system> acl:Execute true
<http://dydra.com/Account1/User1> acl:Read true
<http://dydra.com/Account1/User1> acl:Write true
<http://dydra.com/Account1/User1> acl:Execute true
<urn:dydra:requestContent> acl:Execute true
<urn:dydra:responseContent> acl:Write true

These afford access to the account metadata repository and permits the account owner to modify the ACL graph as well as to modify the account itself. For any repository, these capabilities are extended with

<http://dydra.com/Account1/Repository1> acl:Read true
<http://dydra.com/Account1/Repository1> acl:Write true
<http://dydra.com/Account1/Repository1> acl:Execute true

Anonymous access to queries (inline or view) and to repository data must be authorized. In the same manner cross-account federated access must also be authorized.

Request Processing

The authorization search is implemented by queries which are stored as views in the account metadata repository. There are two. One computes direct access permissions and the other permissions which are inferred based on indirect relations among entities.

• direct-access-authorization : compute the access permitted for a request agent to a given target based on direct ACG assertions.

• inferred-access-authorization : compute the access permitted for a request agent to a given repository based on inferred assertions.

Direct Relationships

If neither exists, the following serve to locate direct access assertions for a given ?target and ?mode combination

prefix acl: <http://www.w3.org/ns/auth/acl>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix prov: <http://www.w3.org/ns/prov#>
select ?mode
where {
  { # an acl entry permits explicit access
    [ acl:accessTo ?target;
      acl:mode ?mode ;
      acl:agent ?agent ] }
  union
  { # an acl entry permits explicit access view membership/specialization
    { { ?mediator prov:hadMember ?agent .}
      union
      { ?agent rdf:type ?mediator .} }
    [ acl:accessTp ?target;
      acl:mode ?mode ;
      acl:agent ?mediator ]
  }
}

In this process, where the request specifies a view, the view term value is the absolute analog to the request url, where the authority has been replaced with just the service host - by default, dydra.com, and the scheme with http. If the request includes the query expression inline, the view term is <urn:dydra:requestContent>. The target repository is designated by the resource corresponding to the first two elements in the URL path.

Inferred Relationships & Groups

Using Dydra one can define “group” and “nested group” (hierarchical and inherited) relationships. In addition to direct assertions, Dydra authorization graphs may specify access through indirect relations.

These include subtype, which can be used to express relations among agents and containment relations among target entities (resources).

These may be defined explicitly in the target’s respective metadata repository and interpreted by an inferred-access-authorization view.

If no definition is present for that view, the following view and relations apply.

• the user is a member of some entity which has the intended access

• the user is of a typed class which has the intended access

• the active authenticated account is a member of some entity which as the intended access

• the active view is a member of some entity which has the inteded access

• the active repository is a member of some entity which has the intended access

prefix acl: <http://www.w3.org/ns/auth/acl>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix prov: <http://www.w3.org/ns/prov#>
select ?target
where {
  { # the user has the intened access
    [ acl:accessTo ?target;
      acl:mode ?mode ;
      acl:agent ?mediator . ] }
  { { ?mediator prov:hadMember* ?agent . }
    union
    { ?agent a ?type .
      ?type rdfs:subClass* ?mediator . }
    union
    { ?mediator prov:hadMember* ?account . }
    union
    { ?mediator prov:hadMember* ?view . }
    union
    { ?mediator prov:hadMember* ?repository . }
  }
}

Target Entity Composition

The entity classes are governed by the following definition:

foaf:Agent rdf:type rdfs:Class .
foaf:Person rdf:type rdfs:Class .
sioc:UserAccount rdf:type rdfs:Class .
<http://purl.org/dc/terms/Dataset> rdf:type rdfs:Class .
<urn:dydra:Account> rdf:type rdfs:Class .
<urn:dydra:Account> rdfs:subClassOf sioc:UserAccount .
<urn:dydra:Group> rdf:type rdfs:Class .
<urn:dydra:Repository> rdf:type rdfs:Class .
<urn:dydra:Repository> rdfs:subClassOf <http://purl.org/dc/terms/Dataset> .
?account prov:hadMember ?repository .

Agent Type

The relation among agent classes is governed by the following definition:

<urn:dydra:AuthenticatedAgent> rdf:type rdfs:Class .
<urn:dydra:AuthenticatedAgent> rdfs:subClassOf foaf:Agent .
<urn:dydra:User> rdf:type rdfs:Class .
<urn:dydra:User> rdfs:subClassOf foaf:AuthenticatedAgent .
<urn:dydra:User> rdfs:subClassOf foaf:Person .
<urn:dydra:LocatedAgent> rdf:type rdfs:Class .
<urn:dydra:LocatedAgent> rdfs:subClassOf foaf:Agent .
<urn:dydra:Manager> rdfs:subClassOf <urn:dydra:User> .
<urn:dydra:Administrator> rdfs:subClassOf <urn:dydra:Manager> .
?user acl:owner ?account