Re: Access Control Note

On 8/6/14 9:34 PM, Ashok Malhotra wrote:
> Some quad stores provide access to individual triples.

Yes, Virtuoso does that.

> I know that Oracle allows that and our product folks would like to
> provide access control at the triple level.

Virtuoso supports ACLs scoped to named graph IRIs. For all the reasons 
already outlined in prior posts from Sandro, Henry, and I.

> Thus, I am reluctant to remove this requirement.

Sorry, but the requirement reflects misunderstanding of the role of 
named graphs in relation to triples.

Look at it this way, from an RDBMS that supports RDF perspective:

1. A named graph denotes an internal document identifier -- remember, a 
Table is a document in an RDBMS (because a database != rdbms system; 
they are distinct things)

2. You protect documents not specific sentences and paragraphs in 
documents -- redaction isn't the same thing as ACLs, in the case of ACLs 
you are (like in the real world) controlling access to documents in a 
folder, cabinet, cube, building etc.. all of which relate directly to 
the subject at hand here.


Even if you tried to implement triple scoped ACLs, it would die of 
inflexibility and horrific performance. Scalability is not even a 
discussion.

Here's an example of a Named Graph ACL template, represented in Turtle 
Notation:

## Protected (Private) Resource Authorization denoted by the IRI 
<{ACL-IRI}> ;
## created by the Identity Principal denoted by the IRI 
<{Rule-Creator-WEBID}> ;
## granting Read/Write privileges to the Named Graph denoted by the IRI 
<{Target-Named-GRAPH-IRI}> ;
## to identity principals denoted by the following IRIs list 
<{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}>,

PREFIX oplacl: <http://www.openlinksw.com/ontology/acl#>
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

<{ACL-IRI}>
a acl:Authorization ;
rdfs:label "ACL based Data Access Policy Example" ;
rdfs:comment """An ACL based Data Access Policy used to control access 
to a specific named graph,
                         denoted by a named graph IRI that functions as 
the object of an ac:accessTo relation.
                         This particular policy grants Read and Write 
privileges to
                         Identity Principals denoted by the list of URIs 
functioning as the object of the acl:agent relation.  """ ;
foaf:maker <{Rule-Creator-WEBID}> ;
oplacl:hasAccessMode oplacl:Read, oplacl:Write  ;
acl:accessTo <{Target-Named-GRAPH-IRI}> ;
acl:agent <{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}> ;
oplacl:hasScope oplacl:PrivateGraphs ;
oplacl:hasRealm oplacl:DefaultRealm .



Kingsley
> All the best, Ashok
>
> On 8/6/2014 2:11 PM, Sandro Hawke wrote:
>> On August 5, 2014 5:52:45 AM EDT, Kingsley Idehen 
>> <kidehen@openlinksw.com> wrote:
>>> On 8/5/14 10:02 AM, henry.story@bblfish.net wrote:
>>>> On 4 Aug 2014, at 23:32, Ashok Malhotra<ashok.malhotra@oracle.com>
>>> wrote:
>>>>>> Henry:
>>>>>> We decided to remove access control for attributes (parts of
>>> triples)
>>>>>> We did not discuss removing access control for triples.
>>>>>> We can discuss this if you wish.
>>>> I don't see how you can do access control on parts of triples at all.
>>>>
>>>> The argument as I understand it is that one can only give access or
>>> not
>>>> at the HTTP layer to a resource. What state of the resource you show
>>>> is another topic: call it filtering. That could be an orthogonal
>>> spec.
>>>> It is best to keep things simple and distinct to arrive at a
>>> consensus.
>>>> Henry
>>>>
>>> +1
>> +1
>>
>>
>>
>
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this