Re: TAC + roles + resource access control = UAC

On 9/6/12 6:32 PM, bergi wrote:
>> I know that managing SPARQL queries with tools is nearly impossible (at
>> least if we are trying to do it in a user friendly way like "allow
>> access to all my friends" or "allow access to all my family members").
> We must be careful. A Graph Rule Language [1] should be used for the
> definition of "all my friends" and "all my family members". At the end
> we will have a big and monolithic ontology, if we try to integrated
> topics like these.
>
>> I think I did not understand the protocol for triple based access
>> control with UAC correctly. How is access evaluated for a user?
> The TAC documentation [2] is currently much better. UAC is based on the
> TAC concept, so the example [3] would be nearly the same in UAC.
>
>> Is it possible to offer an "shielded" SPARQL endpoint with the graph
>> based access control and UAC? I'm thinking of extending remoteStorage
>> enabled servers by an SPARQL endpoint, so that in addition to resource
>> based storage one could also store RDF data and query the linked data
>> with SPARQL.
> I have implemented or planed to implement some modules for ResourceMe to
> cover the triple scenario. That's the current status:
>
> 	RemoteStorage via SPARQL
> There is a working demo, but the ResourceMe framework integration is
> missing.
>
> 	UAC Triplestore Wrapper
> Works. My local version of my profile [4] uses already UAC.
>
> 	SPARQL endpoint
> Basic SPARQL SELECTs are working.
>
> But it's implemented 100% in PHP, so the performance isn't the best. I
> will try to release it soon on GitHub.
>
> There are different opinions about the right position for the access
> control. Danny Ayers also likes the idea of a SPARQL endpoint wrapper. I
> expect to much performance loss. I had already a look at the Jena code.
> The DatasetGraphWrapper class looks like a good base to code an
> AccessControlDatasetGraphWrapper class. What's your opinion? With Plate,
> you have already experience adding access control to Jena.
>
> @Kingsley
> Does Virtuoso offer an API to code access control beside SPARQL ASK?

Yes, but also remember the SPARQL protocol is a RESTful interaction 
mechanism (colloquially an API).

Note, there is inherent power in the simplicity of a document driving 
everything such that end-users, integrators, and programmers are equally 
served.

I am sure you know, SPARQL is the most powerful underlying mechanism for 
resource ACLs.
>
>> The s4ac ontology used by shi3ld is not limited to graph based access
>> control, the s4ac:appliesTo property [1] refers to the protected
>> resource, thus this could be a resource in my remoteStorage or an graph
>> in my SPARQL endpoint.
> Thanks for the hint. I haven't noticed that before.
>
>> Anyway, thank you for your explanation. I think I just did not wrap my
>> head around UAC yet.
>>
>> Access is only granted based on foaf:agent's, isn't it? What I am
>> missing here are some other dimensions like "access is granted only from
>> 8:00 to 16:00 on working days" or "access is granted only for people 500
>> metres around my local position".
> Assigning roles based on time ranges is on the todo list. "people 500
> meters around my local position" is again something that should be
> covered by a dynamic group based on a Graph Rule Language.

Its a SPARQL ASK query against a graph with the relevant entity 
relationship semantics.
>
>> Basically I just want to build a remoteStorage+SPARQL implementation
>> that could serve as a new way of storing your digital life combined with
>> a flexible (but user friendly) access control management.

You should be able to make a document, publish it to an address, and 
then use ACLs to protect it. The ACL sophistication can be mundane or 
advanced, the key thing is the underpinnings are appropriated handled by 
SPARQL ASK.

I still encourage everyone to start with basic examples and build up. 
This is close to the 3rd year where we've stood on our own re. ACLs for 
SPARQL endpoints and Web resources in general. It would be nice if there 
was a lot of interop work going on at this stage as this is ultimately 
how some much needed clarity comes to the fore. As per usual, there are 
scalability challenges that will come into play with all of this, across 
a variety of scenarios.

> That's also the intention of ResourceMe [5]. It's coded in PHP, because
> that's the language nearly any web space supports. But also it's very
> modular. So it can connect to any SPARQL endpoint and the UAC wrapper
> can be used for access control or, if the SPARQL endpoints supports
> already access control, use the SPARQL endpoint without the wrapper. For
> the second scenario I expect a performance boost. One more reason to
> integrate UAC also into Jena and/or Virtuoso.
>
>
> [1] http://www.w3.org/community/rww/wiki/Scope#Graph_Rule_Language
> [2] http://ns.bergnet.org/tac/0.1/triple-access-control.html
> [3] http://ns.bergnet.org/tac/0.1/triple-access-control.html#sec-example
> [4] https://www.bergnet.org/people/bergi/card#me
> [5] http://resourceme.bergnet.org/
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen