- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 22 Jun 2006 11:41:54 +0100
- To: "Hans Teijgeler" <hans.teijgeler@quicknet.nl>, "SW-forum" <semantic-web@w3.org>
- Cc: "Paap, Onno" <onno.paap@gmail.com>
-------- Original Message -------- > From: Hans Teijgeler <> > Date: 21 June 2006 14:34 > > Hi, > > Thanks to all who responded! > > Now my next problem: > > Given the fact that the security aspects of SPARQL were hardly (if at > all) addressed I get the impression that this was because the SW > supposedly has nothing but public domain accessible information. That is not the reason - security of information is achieved by securing the SPARQL endpoint. All the mechansims for either http or SOAP apply to the SPARQL protocol; that's a good reason for the SPARQL protocol using WSDL because it reuses, rather than reinvents, a lot of security and deployment stuff. > That is of course not so. > So we were told that we should solve that through the HTTP or HTTPS > security provisions. Fine, if one is a security expert. I'm not, so I > am looking for some advice, in particular on what to read and what to > do or avoid when implementing SPARQL in an HTTPS environment, with LOTS > of triple stores accessible by one SPARQL query, often cascaded (after > all the SW is aka distributed data base). > > Can anyone help us? > > Regards, > Hans Many application servers provide this for the developer - that would be a good place to start; adopt an existing frmaework. As with any security design, you'll need to scope out what you are protecting against. Andy
Received on Thursday, 22 June 2006 10:42:11 UTC