Re: SPARQL Security - Best Practices?

Having implemented several database-driven access control systems, I would
argue that you should make the access control transparent to the user, and
enforce the control you want as close to the raw data as possible.

This means filtering at the db level, not modifying the SPARQL queries to
enforce control.  Modifying user queries on the fly is difficult to get
right in all circumstances, and may lead to erroneous results or really
poorly performing queries.

You are then free to change your access control implementation or your
SPARQL implementation, without affecting the other much.  Since the access
control is happening close to the data (e.g. using a view), even if you use
another technology or query language to access the data, access control will
still be operating on it.

Regards,

Matt Palmer.

On Wed, Sep 3, 2008 at 12:54 AM, Brian Manley <brian.manley@gmail.com>wrote:

>
>
> On Sep 2, 2008, at 4:06 PM, Richard Newman wrote:
>
>
>>  A couple of years ago I was working on a system that very heavily used
>>>> very complex access control. My ultimate conclusion was that standard SPARQL
>>>> was not very well suited to this kind of thing. That's an interesting
>>>> conclusion for a SPARQL implementor to draw, but there you are :)
>>>>
>>>
>>> Are any query languages suited to this?
>>>
>>
>> Probably not! I expect that any language sufficiently powerful would
>> either be a full-fledged programming language (cf. Prolog, which is one of
>> the query interfaces AllegroGraph supports, and which could implement this
>> sort of thing), or be too closely tied to an implementation to be
>> standardized.
>>
>> SPARQL is interesting here because features like datasets, GRAPH, etc.
>> conspire to *appear* like the components one would need to build a
>> graph-based in-query access control system, when in fact they are
>> insufficient. I've had a number of people ask about it, and discussion of
>> the pros and cons can become involved, particularly for people who are "just
>> users".
>>
>> Access control might be one of those things that is best left up to the
>> implementation.
>>
>>
> Thanks to all for the great discussion regarding this!
>
> I tend to agree with you on your last point. Beyond the issues you already
> pointed out, adding hidden nuances to the meaning of things like a graph
> name or altering the syntax to support this seem to be non-starters. Better
> to drive it deeper into the implementation so that's it's completely
> transparent to the end user.
>
> In the DBMS world, things like "label security"  seem to be implemented
> primarily by automagically modifying the WHERE clause to filter on a column
> that denotes ownership. As an experiment, I think I'll try doing something
> similar by adding another column (OWNER?) to my store (making look like s,
> p, o, owner), and adding WHERE OWNER IS NULL OR OWNER = "XXX" to the SQL
> that I generate from SPARQL.
>
> Alternately, I could just provide another triple for each resource in my
> store and only restrict at the resource level rather than the triple level.
> For example .
>
>        :a      dc:title        "something";
>                :owner  :bmanley .
>
> ...and add an additional triple matching pattern to any SPARQL that gets
> executed that would include or omit it from the results.
>
> Do those seem like reasonable approaches?
>
> Brian
>
>
>
>