As someone who has done a fair bit of stuff around security (HTTP and otherwise) my first reaction was that your proposed approach would be really easy to do both man in the middle and privilege upgrade attacks upon it
If I can see the network requests in plain text then I can simply modify the HTTP header used to pretend to be John Doe and see how much he's earning. So at the very least you want to consider having a secured connection between the web-app and your Fuseki server instance to prevent this. I don't know enough about jena-security to give an authoritative answer on whether there is a better way to do this with Jena security though having a web-app stack in the mix certainly complicates things. Even in the proposed workflow presumably you would need to add some bridging code between Fuseki and jena-security because the security layer doesn't have access to the servlet contexts (which in your proposal contains the real user to do the scans as) directly as I understood it. Rob On 26/01/2015 16:10, "Trevor Donaldson" <[email protected]> wrote: >Updated workflow. Please see below. > >On Mon, Jan 26, 2015 at 7:08 PM, Trevor Donaldson <[email protected]> >wrote: > >> I agree. I should explain a little more what I am trying to do and then >> maybe someone can tell me if there is another way. I am using fuseki2 >>with >> Jena Security. I am using triple level security. For example, don't want >> users to see payroll info for John Doe but they can see John's name >>etc... >> I have the following workflow (Fuseki2, ssl, tomcat): >> >> User Request data from web app -> Authenticate user cert / roles -> web >> app calls Fuseki2 -> jena security (need to validate triples based on >>user >> that requested here) -> return data that only the user can see. >> >> The problem is that Fuseki2 thinks the user that is requesting access >>to a >> triple is the server when in reality it is the user. In order to get >>around >> this I was planning on using a Http Header and pass the username in the >> header. >> >> I don't know another way to accomplish this. If anyone does please let >>me >> know. >> >> On Mon, Jan 26, 2015 at 6:46 PM, Rob Vesse <[email protected]> wrote: >> >>> Well it isn't exactly a common user request (you're the first in the >>>3.5 >>> years or so I've been actively contributing to Jena) hence the lack of >>>any >>> user friendly API for this >>> >>> If you think this is something you'd need to do regularly then we can >>> always add an API for it. >>> >>> QueryExecutionFactory.sparqlService() always returns an instance of >>> QueryEngineHTTP so you can always cast the QueryExecution you get from >>>the >>> sparqlService() call to this and then use specific method calls on >>> QueryEngineHTTP to configure it further. However right now there >>>aren't >>> any method calls that would let you add HTTP headers, there are those >>>that >>> let you add additional request parameters (e.g. to pass custom >>>parameters >>> to endpoints e.g. server side timeouts) so adding complimentary APIs >>>for >>> HTTP headers would make sense. >>> >>> It would perhaps be useful to understand why you need to add custom >>>HTTP >>> headers in the first place? >>> >>> Rob >>> >>> On 26/01/2015 14:57, "Trevor Donaldson" <[email protected]> wrote: >>> >>> >Wow... ok. No clue how to do that. Guess I need to lookup custom >>>request >>> >interceptor >>> >On Jan 26, 2015 5:49 PM, "Rob Vesse" <[email protected]> wrote: >>> > >>> >> Yes though not in any particular user friendly way >>> >> >>> >> The only way you can do it currently is by using the >>>HttpAuthenticator >>> >> subsystem >>>(https://jena.apache.org/documentation/query/http-auth.html) >>> >>and >>> >> passing an instance of a custom authenticator that you wrote >>>yourself >>> to >>> >> the QueryExecutionFactory.sparqlService() call >>> >> >>> >> The custom authenticator could take the AbstractHttpClient instance >>>it >>> >> receives and add a request interceptor that would add in the >>>necessary >>> >> headers to the outgoing requests though would need to be careful >>>not to >>> >> register itself multiple times since client instances can be reused. >>> >> >>> >> Rob >>> >> >>> >> On 26/01/2015 13:01, "Trevor Donaldson" <[email protected]> wrote: >>> >> >>> >> >I would like to add some Http Headers to the request that is made >>>by >>> >> >QueryExecutionFactory.sparqlService. Is this possible? Thanks >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> >>> >>
