W3C home > Mailing lists > Public > semantic-web@w3.org > September 2008

Re: SPARQL Security - Best Practices?

From: Damian Steer <pldms@mac.com>
Date: Tue, 02 Sep 2008 21:45:33 +0100
Cc: semantic-web@w3.org
Message-id: <327DEB33-9BF4-405A-8EFD-DAE15062CB09@mac.com>
To: Brian Manley <brian.manley@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2 Sep 2008, at 18:55, Brian Manley wrote:

>
> All,
>
> Have any best-practices emerged with regard to authentication and  
> authorization for SPARQL endpoints?
>
> It appears that using basic HTTP authentication and security methods  
> (basic realm authentication, SSL, etc. ) are sufficient for access  
> to an endpoint, but what about authorization at the triple level?  
> For example, restricting the triples that are queriable by an  
> authenticated user?
>
> My initial instinct is to use named graphs (user "A" can only query  
> graph "A"). But that seems rather limiting, as I might want to  
> devise a hierarchical authorization scheme where, for example, a  
> manager can query on a subordinate's triples. Perhaps I can take  
> some of the ideas for row-level security in the relational database  
> world (though everything I find is patented).

Here at the ILRT we have a project that works along these lines. I  
agree your scheme is a bit limited, but it's not hard to improve.

So, as you suggest, we use graphs as the basis. We then mix in a  
function P(A,G) => boolean, which tells us whether user A has  
permission to query G. (or, indeed, to write or delete)

You've used A == G as you function, but there's nothing to stop you  
using a fully featured permission system with roles, groups, managers,  
admins, etc. like Permis. [1]

(The actual system I've been playing with is using openid. Each openid  
gets two graphs: openid#public and openid#private. The openid bit is  
my dubious hack, but the rest is rather better thought out by Mike)

You could then rewrite incoming queries like this:

SELECT ?privateinfo WHERE { :damian :knows ?privateinfo }

becomes

SELECT ?privateinfo WHERE { GRAPH ?g { :damian :knows ?privateinfo }  
FILTER (?g = <allowed> || ?g = <alsoallowed>) } # please forgive my  
syntax here

(which excludes named graph queries, I guess)

but we've inclined towards:

SELECT ?privateinfo ?g WHERE { GRAPH ?g { :damian :knows ? 
privateinfo } }

and then filtering on ?g ourselves.

I've said 'we' a lot here, but Mike Jones is actually working this  
stuff out. We're planning to talk about it at the SWIG get together at  
HP labs in november,

Damian

[1] <http://sec.cs.kent.ac.uk/permis/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAki9pe0ACgkQAyLCB+mTtymtwwCfeM05LxU3EWD/sCC0XFN8vZ39
Hq8AoPLM1Zc08S8qBalzDxzonHQk+shn
=lkxL
-----END PGP SIGNATURE-----
Received on Tuesday, 2 September 2008 20:46:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:25 GMT