Access control and the Glitter/SPARQL endpoint
Paul Trevithick
Now we wish to expose these data in the Anzo server as SPARQL while continuing to have the benefits of the SPARQL consumer only having access to the graphs it should.
Does the Glitter engine restrict access to only the graphs that are permissioned for that consumer based on some kind of username/password authentication? Has a convention emerged in the Linked Data community as to how to control access to a SPARQL endpoint? It seems like requiring an OAuth token would be a good pattern.
Paul
Jordi Albornoz Mulligan
> We've been accessing the Anzo server using the Anzo Javascript and Java clients. Doing so allows our apps to authenticate to the server and gain access only to only the graphs that they should gain access to based on the meta-graph's access control policy. This all works well.
>
> Now we wish to expose these data in the Anzo server as SPARQL while continuing to have the benefits of the SPARQL consumer only having access to the graphs it should.
>
> Does the Glitter engine restrict access to only the graphs that are permissioned for that consumer based on some kind of username/password authentication?
Yes. OpenAnzo's SPARQL support completely observes the access control
placed on named graphs. The SPARQL endpoint requires a username and
password. By default, you supply the username and password via HTTP
Basic Authentication.
> Has a convention emerged in the Linked Data community as to how to control access to a SPARQL endpoint? It seems like requiring an OAuth token would be a good pattern.
I'm not sure about a consensus. HTTP Basic Auth is, of course, a common
method. OAuth would certainly be nice but Open Anzo does not support it
yet. The authentication system for the HTTP services (like the SPARQL
endpoint) is an extensible aspect of Open Anzo though. Besides HTTP
Basic Authentication, we support a cookie-based token approach,
essentially a Form Based Authentication approach.
If you were interested, you could extend it to include another
authentication approach. Open Anzo embeds Jetty for its HTTP server and
implementing a new authentication scheme is similar to implementing a
custom Authenticator[1] in Jetty.
1.
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/security/Authenticator.html
--
Jordi Albornoz Mulligan
Founding Engineer - Cambridge Semantics
jo...@cambridgesemantics.com
(617) 401-7321
Paul Trevithick
On Feb 22, 2011, at 9:33 AM, Jordi Albornoz Mulligan wrote:
> On 2/19/2011 5:49 PM, Paul Trevithick wrote:
>> We've been accessing the Anzo server using the Anzo Javascript and Java clients. Doing so allows our apps to authenticate to the server and gain access only to only the graphs that they should gain access to based on the meta-graph's access control policy. This all works well.
>>
>> Now we wish to expose these data in the Anzo server as SPARQL while continuing to have the benefits of the SPARQL consumer only having access to the graphs it should.
>>
>> Does the Glitter engine restrict access to only the graphs that are permissioned for that consumer based on some kind of username/password authentication?
>
> Yes. OpenAnzo's SPARQL support completely observes the access control
> placed on named graphs. The SPARQL endpoint requires a username and
> password. By default, you supply the username and password via HTTP
> Basic Authentication.
Great thanks.
>
>> Has a convention emerged in the Linked Data community as to how to control access to a SPARQL endpoint? It seems like requiring an OAuth token would be a good pattern.
>
> I'm not sure about a consensus. HTTP Basic Auth is, of course, a common
> method. OAuth would certainly be nice but Open Anzo does not support it
> yet. The authentication system for the HTTP services (like the SPARQL
> endpoint) is an extensible aspect of Open Anzo though. Besides HTTP
> Basic Authentication, we support a cookie-based token approach,
> essentially a Form Based Authentication approach.
>
> If you were interested, you could extend it to include another
> authentication approach. Open Anzo embeds Jetty for its HTTP server and
> implementing a new authentication scheme is similar to implementing a
> custom Authenticator[1] in Jetty.
>
> 1.
> http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/security/Authenticator.html
Thanks. That's great to know. I think we will indeed implement an OAUTH Authenticator at some point soon.
If, in addition to the SPARQL endpoint, we wanted to expose Linked Data resource URIs (per [1]) would we use something like Pubby [2]? Other ideas?
[1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
[2] http://www4.wiwiss.fu-berlin.de/pubby/
Jordi Albornoz Mulligan
On 2/22/2011 7:08 PM, Paul Trevithick wrote:
> If, in addition to the SPARQL endpoint, we wanted to expose Linked Data resource URIs (per [1]) would we use something like Pubby [2]? Other ideas?
>
> [1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
> [2] http://www4.wiwiss.fu-berlin.de/pubby/
Pubby itself won't work out-of-the-box, I believe, because Open Anzo
doesn't handle DESCRIBE queries by default and, if I understand
correctly, Pubby requires DESCRIBE queries. But the approach is fine.
Although, you can actually use a slightly different approach that may or
may not be simpler for you. The Open Anzo server itself though can host
a Java Servlet. You could write or modify one to implement the linked
open data HTTP conventions. That servlet can just use the AnzoClient API
to retrieve the contents of a graph and serve them up as the HTTP
response. Open Anzo includes the ability to serialize RDF to various
formats.
Adding a servlet to Open Anzo is fairly simple. It essentially involves
bundling up the servlet as an OSGi bundle and including a bit of
configuration. There is a very simple servlet project that you can use
as an example at:
http://www.openanzo.org/projects/openanzo/browser/openanzo/trunk/org.openanzo.servlet.validation
That project includes all of the OSGi wizardry and configuration and the
servlet is a basic, almost 'hello world' usage of the AnzoClient API.
One thing to consider is whether you care about authentication for the
data you serve in that way. If you want it to be out in the open without
authentication then you should look enabling the anonymous access using
the 'org.openanzo.security.ldap.anonymousAccessEnabled' property. That
enables connecting via the API as the built-in 'anzo_anonymous' user
which accepts anything as a password. Access control is still enforced.
The anonymous user can only see things that explicitly grant it access
or that grant access to 'everyone'. There is built-in group called
'authenticated users' which will grant access to everyone except
anonymous users.
At Cambridge Semantics we've actually built such a servlet to serve data
using linked open data conventions but it's currently not open source
and I'm not sure of the current plans to open source it.
Paul Trevithick
> --
> You received this message because you are currently subscribed to the "OpenAnzo" group.
>
> To post to this group, send email to open...@googlegroups.com
> To unsubscribe from this group, send email to openanzo-u...@googlegroups.com
>
> For more options, visit this group at http://groups.google.com/group/openanzo?hl=en