- From: Damian Steer <pldms@mac.com>
- Date: Tue, 02 Sep 2008 21:45:33 +0100
- To: Brian Manley <brian.manley@gmail.com>
- Cc: semantic-web@w3.org
-----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 UTC