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 <[email protected]> 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:// [email protected]/peterlawrence/test/sparql> > { ?s ?p ?o > > } > } > > Unfortunately none of the authentication schemes offered by the endpoint > seems to work. The authentication takes the form of > > http://[email protected]/peterlawrence/test/sparql > > or with a fake password > > http://XYZ123456:[email protected]/peterlawrence/test/sparql > > or as a query string parameter: > > http://dydra.com/peterlawrence/test/sparql?auth_token=XYZ123456 > > or as username:password > > http://peterlawrence:[email protected]/peterlawrence/test/sparql > > Any suggestions? > > Many thanks -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
