Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-1455

Document how to lock down a public NSS server

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: NanoSparqlServer
    • Labels:
      None

      Description

      Develop a wiki page that documents how to lock down a public REST end point such that it supports all query operations against a specified (single) namespace, including queries that use POST. See the email below for a summary of the REST APIs that relate to this ticket. The multi-tenancy API should not be part of the default "lock down". The default lock down could be only for the default namespace.

      Provide the necessary web.xml to support this.

      Capture the deployment lock down guidance developed for the wikidata service, including service whitelists, time limits on operations, read-only end point, etc.

      How to grant someone read-only access to NanoSparqlServer?
      
      The readOnly context-param won't work AFAIU, because I still want to write, I just want to limit certain requests to be read-only.
      
      We have a bigdata instance running behing a firewall and a public front-end. We want to expose an API for other apps to post SPARQL queries. I didn't want to reinvent the wheel, so I just wrote a trivial proxy servlet, based on https://github.com/mitre/HTTP-Proxy-Servlet. With it I was able to expose the entire NanoSparqlServer functionality in our frontend.
      
      Then I started extending my servlet to detect mutating requests and reject them. This turned out to be tricky.
      
      I wanted to allow all kinds of queries:
       - GET and POST with 'query' parameter, CONSTRUCT, SELECT, ASK, DESCRIBE
       - ESTCARD and HASSTMT
       - with all allowed parameters (s=, p=, o=, exact=true, etc.)
       - with all supported output formats
      
      But I wanted to refuse all kinds of mutations
       - everything with 'update' parameter, including those with both 'query' and 'update', GET and POST
       - POST with body
       - POST with uri
       - POST with multipart form data
       - DELETE all
       - DELETE with a triple pattern
       - PUT with a query and a body
      
      After a while I got my proxy servlet to cover all those cases, but now I ask myself: is there a better way? The code I wrote seems brittle. I don't know if it really covers everything and it will have to be adapted if the API changes in future versions of Blazegraph.
      
      

        Attachments

          Activity

            People

            Assignee:
            igorkim igorkim
            Reporter:
            bryanthompson bryanthompson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated: