Accessing a SPARQL endpoint that requires authentication
927 views
Skip to first unread message
Peter Lawrence
Mar 16, 2012, 10:53:33 AM3/16/12
to topbrai...@googlegroups.com
I am trying to access an external SPARQL endpoint (Dydra) that requires authentication from with a TB SPARQL query such as
Unfortunately none of the authentication schemes offered by the endpoint seems to work. The authentication takes the form of
or with a fake password
or as a query string parameter:
or as username:password
Any suggestions?
Many thanks
Scott Henninger
Mar 19, 2012, 4:45:12 PM3/19/12
to TopBraid Suite Users
Peter; This is not a syntax that we support - i.e. placing the
password in a query string. Not very secure, either. The way
authentication to secure endpoints is usually addressed is at the
container level. I.e. if you ping a secured Web service address
(SPARQL endpoints are just a specific kind of Web service), then the
container, such as Tomcat, should initiate a challenge-response
authentication. This is also how TopBraid Live's SPARQL endpoint, and
Web services for that matter, work.
Insofar as the Dydra method of authentication is concerned, there are
some issues we will look into. One is that the version of Jena we use
does not allow the '@' character in IRIs. So syntactically, this is
problematic. There are some recent modifications to Jena that will
allow query strings. We will update to the latest version of Jena and
ARQ within the next couple of months.
Until then, we do not have a solution to this issue other than using
Web container authentication, ala the first paragraph. That seems
like the best option. Unfortunately, this will not work from the
Composer SPARQL View, as it will not prompt for user id and password.
It will work from Web-based TopBraid Live approaches, such as SWP or
HTML (for an example, see http://topquadrantblog.blogspot.com/search/label/SPARQL%20endpoint).
We can look into Composer enhancements to open a login page when a
challenge-response occurs. But, as stated, this will work in TBL
applications.
Another alternative I know some customers have used is to work with
the service provider (I assume that is you in this case) to provide IP
address for the firewall or create a single-signon approach that
authenticates your TBL or TBC, again outside of the SPARQL query.
All of that aside I'm really curious how one could see putting the id/
pwd in the SPARQL SERVICE URL as a secure approach? Even if HTTPS is
used, the seemingly fatal mistake is saving the password in clear text
wherever the SPARQL query is stored. This is normally not an
acceptable level of security, but I'd be interested in being informed
otherwise...
-- Scott
On Mar 16, 9:53 am, Peter Lawrence <peter.lawre...@inova8.com> wrote:
> I am trying to access an external SPARQL endpoint (Dydra) that requires
> authentication from with a TB SPARQL query such as
>
> SELECT ?s ?p ?o
> WHERE {
> SERVICE <http:// XYZ123...@dydra.com/peterlawrence/test/sparql>
>
> Any suggestions?
>
> Many thanks
password in a query string. Not very secure, either. The way
authentication to secure endpoints is usually addressed is at the
container level. I.e. if you ping a secured Web service address
(SPARQL endpoints are just a specific kind of Web service), then the
container, such as Tomcat, should initiate a challenge-response
authentication. This is also how TopBraid Live's SPARQL endpoint, and
Web services for that matter, work.
Insofar as the Dydra method of authentication is concerned, there are
some issues we will look into. One is that the version of Jena we use
does not allow the '@' character in IRIs. So syntactically, this is
problematic. There are some recent modifications to Jena that will
allow query strings. We will update to the latest version of Jena and
ARQ within the next couple of months.
Until then, we do not have a solution to this issue other than using
Web container authentication, ala the first paragraph. That seems
like the best option. Unfortunately, this will not work from the
Composer SPARQL View, as it will not prompt for user id and password.
It will work from Web-based TopBraid Live approaches, such as SWP or
HTML (for an example, see http://topquadrantblog.blogspot.com/search/label/SPARQL%20endpoint).
We can look into Composer enhancements to open a login page when a
challenge-response occurs. But, as stated, this will work in TBL
applications.
Another alternative I know some customers have used is to work with
the service provider (I assume that is you in this case) to provide IP
address for the firewall or create a single-signon approach that
authenticates your TBL or TBC, again outside of the SPARQL query.
All of that aside I'm really curious how one could see putting the id/
pwd in the SPARQL SERVICE URL as a secure approach? Even if HTTPS is
used, the seemingly fatal mistake is saving the password in clear text
wherever the SPARQL query is stored. This is normally not an
acceptable level of security, but I'd be interested in being informed
otherwise...
-- Scott
On Mar 16, 9:53 am, Peter Lawrence <peter.lawre...@inova8.com> wrote:
> I am trying to access an external SPARQL endpoint (Dydra) that requires
> authentication from with a TB SPARQL query such as
>
> SELECT ?s ?p ?o
> WHERE {
> { ?s ?p ?o
>
> }
> }
>
> Unfortunately none of the authentication schemes offered by the endpoint
> seems to work. The authentication takes the form of
>
> http://XYZ123...@dydra.com/peterlawrence/test/sparql
>
> }
> }
>
> Unfortunately none of the authentication schemes offered by the endpoint
> seems to work. The authentication takes the form of
>
>
> or with a fake password
>
> http://XYZ123456:X...@dydra.com/peterlawrence/test/sparql
>
> or as a query string parameter:
>
> http://dydra.com/peterlawrence/test/sparql?auth_token=XYZ123456
>
> or as username:password
>
> http://peterlawrence:passw...@dydra.com/peterlawrence/test/sparql
> or with a fake password
>
> http://XYZ123456:X...@dydra.com/peterlawrence/test/sparql
>
> or as a query string parameter:
>
> http://dydra.com/peterlawrence/test/sparql?auth_token=XYZ123456
>
> or as username:password
>
>
> Any suggestions?
>
> Many thanks
Peter Lawrence
Mar 20, 2012, 9:27:31 AM3/20/12
to topbrai...@googlegroups.com
Scott
Thanks for the response, albeit disappointing.
To defend Dydra I should clarify that the XYZ123456 I used in the example is not a password but a temporary authentication identifier. I can get Dydra to regenerate a new key at anytime. Still not 100% secure but does provide some level of security for a SPARQL endpoint. After all other endpoints have no security at all.
As we all trying to merge information from multiple endpoints, fulfilling the promise of an open data world empowered by RDF, perhaps this should be an extension of the SPARQL1.1 SERVICE definition, as it is a problem that is likely to reoccur.
Thanks for the help
Peter
Many thanks
Scott Henninger
Mar 20, 2012, 1:45:26 PM3/20/12
to TopBraid Suite Users
Peter; Extensions for security for SPARQL 1.1 are probably too late in
the process, but you can check with the W3C committee.
Re-generating a key doesn't sound like a good solution to me. Unless
I'm misunderstanding the technique, if there were 35 SERVICE queries
in your application, then you'd have to make 35 changes to the SERVICE
URI each time a new key is generated. Possibly labor-intensive and
error-prone. Really, it's most secure and most convenient to leave
authentication to the Web application container.
Thanks for the inquiry and we will look into various issues for
accessing secure SPARQL endpoints for 3.6.1.
-- Scott
On Mar 20, 8:27 am, Peter Lawrence <peter.lawre...@inova8.com> wrote:
> Scott
>
> Thanks for the response, albeit disappointing.
>
> To defend Dydra I should clarify that the XYZ123456<http://XYZ123...@dydra.com/peterlawrence/test/sparql> I
the process, but you can check with the W3C committee.
Re-generating a key doesn't sound like a good solution to me. Unless
I'm misunderstanding the technique, if there were 35 SERVICE queries
in your application, then you'd have to make 35 changes to the SERVICE
URI each time a new key is generated. Possibly labor-intensive and
error-prone. Really, it's most secure and most convenient to leave
authentication to the Web application container.
Thanks for the inquiry and we will look into various issues for
accessing secure SPARQL endpoints for 3.6.1.
-- Scott
On Mar 20, 8:27 am, Peter Lawrence <peter.lawre...@inova8.com> wrote:
> Scott
>
> Thanks for the response, albeit disappointing.
>
> used in the example is not a password but a temporary authentication
> identifier. I can get Dydra to regenerate a new key at anytime. Still not
> 100% secure but does provide some level of security for a SPARQL endpoint.
> After all other endpoints have no security at all.
>
> As we all trying to merge information from multiple endpoints, fulfilling
> the promise of an open data world empowered by RDF, perhaps this should be
> an extension of the SPARQL1.1 SERVICE definition, as it is a problem that
> is likely to reoccur.
>
> Thanks for the help
>
> Peter
>
>
>
>
>
>
>
> On Friday, March 16, 2012 10:53:33 AM UTC-4, Peter Lawrence wrote:
>
> > I am trying to access an external SPARQL endpoint (Dydra) that requires
> > authentication from with a TB SPARQL query such as
>
> > SELECT ?s ?p ?o
> > WHERE {
> > SERVICE <http:// XYZ123...@dydra.com/peterlawrence/test/sparql>
> identifier. I can get Dydra to regenerate a new key at anytime. Still not
> 100% secure but does provide some level of security for a SPARQL endpoint.
> After all other endpoints have no security at all.
>
> As we all trying to merge information from multiple endpoints, fulfilling
> the promise of an open data world empowered by RDF, perhaps this should be
> an extension of the SPARQL1.1 SERVICE definition, as it is a problem that
> is likely to reoccur.
>
> Thanks for the help
>
> Peter
>
>
>
>
>
>
>
> On Friday, March 16, 2012 10:53:33 AM UTC-4, Peter Lawrence wrote:
>
> > I am trying to access an external SPARQL endpoint (Dydra) that requires
> > authentication from with a TB SPARQL query such as
>
> > SELECT ?s ?p ?o
> > WHERE {
> > { ?s ?p ?o
> > }
> > }
>
> > Unfortunately none of the authentication schemes offered by the endpoint
> > seems to work. The authentication takes the form of
>
> > http://XYZ123...@dydra.com/peterlawrence/test/sparql
> > }
> > }
>
> > Unfortunately none of the authentication schemes offered by the endpoint
> > seems to work. The authentication takes the form of
>
>
> > or with a fake password
>
> > http://XYZ123456:X...@dydra.com/peterlawrence/test/sparql
>
> > or as a query string parameter:
>
> >http://dydra.com/peterlawrence/test/sparql?auth_token=XYZ123456
>
> > or as username:password
>
> > or with a fake password
>
> > http://XYZ123456:X...@dydra.com/peterlawrence/test/sparql
>
> > or as a query string parameter:
>
> >http://dydra.com/peterlawrence/test/sparql?auth_token=XYZ123456
>
> > or as username:password
>
Reply all
Reply to author
Forward
0 new messages