- 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