You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Bardo Nelgen <ma...@bnnperformances.de> on 2021/05/19 09:36:42 UTC
Federated Query with credentials
Hi all,
on good old Fuseki 2.6.0 I could use the IRL of <SERVICE> requests to
transmit required HTTP basic credentials to access Fuseki.
Obviously this is not possible any longer with the current version –
not even for localhost.
As using a reverse proxy to restrict access even from the local
environment to me appears somewhat impractical:
What is the "correct" way to locally control Fuseki access while still
intending to play by the rules ? :-)
As always, any hint or pointer is highly appreciated.
Best,
Bardo
Re: Federated Query with credentials
Posted by Andy Seaborne <an...@apache.org>.
Ah - I read it as using SERVICE so you could send auth conveniently
which I have seen before.
The query execution context can have a HttpClient passed to it.
I thought this was in the documentation or an example somewhere but I
can't find it.
https://jena.apache.org/documentation/javadoc/arq/org/apache/jena/sparql/engine/http/Service.html
and examples of use from the tests:
https://github.com/apache/jena/blob/main/jena-arq/src/test/java/org/apache/jena/sparql/engine/http/TestService.java
which at its core is:
String serviceURL = "http://....";
// Put in a map of Service URL to context inthe global context
// (Can be per query rather than global if desired)
Map<String, Context> serviceContextMap = new HashMap<>();
ARQ.getContext().put(Service.serviceContext, serviceContextMap);
// Create context with HttpClient.
Context serviceContext = new Context(ARQ.getContext());
HttpClient testClient = HttpClients.custom().build(); // Add auth
serviceContext.put(Service.queryClient, testClient);
// Put in global map for serviceURL
serviceContextMap.put(serviceURL, new Context(ARQ.getContext()));
.. make query...
Andy
On 20/05/2021 12:13, Bardo Nelgen wrote:
> Thanks a lot, Andy.
>
> And sorry, it seems I probably formulated my question the wrong way around:
>
> How can I use your described approach for a federated sub-query, for
> which (as it is embedded inside an outer query) one seemingly cannot
> easily transmit separate/different credentials via
> RDFConnectionRemoteBuilder.
>
> As mentioned, formerly I simply put the credentials inside the federated
> IRL, which was fine, as it’s just going to localhost for now.
>
> But since the update to the latest Jena/Fuseki version, I keep getting a
> "Bad IRI" error
>
>> Code: 58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is
>> prohibited by the scheme is present.
In 4.0.0 it can be overzealous
It will remain a wanring, but be passed through.
Using the HttpClient mechanism is better.
> until I remove the credentials from the <service> IRL.
>
> For the outer query, of course, RDFConnectionRemoteBuilder does the job
> as expected (with Fuseki running in a different context than the main
> application; in future possibly on a separate machine).
>
> Quite obviously, I’m missing something here… – just have absolutely no
> clue any more what it might be.
>
> Probably something with the "credsProvider"/"AuthSetup" features ? Or a
> preset/config file to be placed somewhere ?
>
> Again, thanks for looking into this.
>
> Best,
> Bardo
>
> On 19.05.21 19.34 Uhr, Andy Seaborne wrote:
>> Bardo,
>>
>> On the server side:
>>
>> https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
>>
>>
>> Access control on the server, dataset URL, or endpoint.
>>
>> Also on the data with graph access control lists.
>>
>> You can also use Apache Shiro.
>> https://jena.apache.org/documentation/fuseki2/fuseki-security
>> and
>> https://jena.apache.org/documentation/permissions/
>>
>> On the client side:
>>
>> https://jena.apache.org/documentation/rdfconnection/
>>
>> RDFConnectionRemoteBuilder
>>
>> and pass in an appropriate HttpClient (Apache HttpClient).
>>
>> Andy
>>
>> On 19/05/2021 10:36, Bardo Nelgen wrote:
>>> Hi all,
>>>
>>> on good old Fuseki 2.6.0 I could use the IRL of <SERVICE> requests to
>>> transmit required HTTP basic credentials to access Fuseki.
>>>
>>> Obviously this is not possible any longer with the current version –
>>> not even for localhost.
>>>
>>> As using a reverse proxy to restrict access even from the local
>>> environment to me appears somewhat impractical:
>>>
>>> What is the "correct" way to locally control Fuseki access while
>>> still intending to play by the rules ? :-)
>>>
>>> As always, any hint or pointer is highly appreciated.
>>>
>>> Best,
>>> Bardo
>>>
Re: Federated Query with credentials
Posted by Bardo Nelgen <ma...@bnnperformances.de>.
Thanks a lot, Andy.
And sorry, it seems I probably formulated my question the wrong way around:
How can I use your described approach for a federated sub-query, for
which (as it is embedded inside an outer query) one seemingly cannot
easily transmit separate/different credentials via
RDFConnectionRemoteBuilder.
As mentioned, formerly I simply put the credentials inside the federated
IRL, which was fine, as it’s just going to localhost for now.
But since the update to the latest Jena/Fuseki version, I keep getting a
"Bad IRI" error
> Code: 58/PROHIBITED_COMPONENT_PRESENT in USER: A component that is
> prohibited by the scheme is present.
until I remove the credentials from the <service> IRL.
For the outer query, of course, RDFConnectionRemoteBuilder does the job
as expected (with Fuseki running in a different context than the main
application; in future possibly on a separate machine).
Quite obviously, I’m missing something here… – just have
absolutely no clue any more what it might be.
Probably something with the "credsProvider"/"AuthSetup" features ?
Or a preset/config file to be placed somewhere ?
Again, thanks for looking into this.
Best,
Bardo
On 19.05.21 19.34 Uhr, Andy Seaborne wrote:
> Bardo,
>
> On the server side:
>
> https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
>
>
> Access control on the server, dataset URL, or endpoint.
>
> Also on the data with graph access control lists.
>
> You can also use Apache Shiro.
> https://jena.apache.org/documentation/fuseki2/fuseki-security
> and
> https://jena.apache.org/documentation/permissions/
>
> On the client side:
>
> https://jena.apache.org/documentation/rdfconnection/
>
> RDFConnectionRemoteBuilder
>
> and pass in an appropriate HttpClient (Apache HttpClient).
>
> Andy
>
> On 19/05/2021 10:36, Bardo Nelgen wrote:
>> Hi all,
>>
>> on good old Fuseki 2.6.0 I could use the IRL of <SERVICE> requests to
>> transmit required HTTP basic credentials to access Fuseki.
>>
>> Obviously this is not possible any longer with the current version
>> – not even for localhost.
>>
>> As using a reverse proxy to restrict access even from the local
>> environment to me appears somewhat impractical:
>>
>> What is the "correct" way to locally control Fuseki access while
>> still intending to play by the rules ? :-)
>>
>> As always, any hint or pointer is highly appreciated.
>>
>> Best,
>> Bardo
>>
Re: Federated Query with credentials
Posted by Andy Seaborne <an...@apache.org>.
Bardo,
On the server side:
https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
Access control on the server, dataset URL, or endpoint.
Also on the data with graph access control lists.
You can also use Apache Shiro.
https://jena.apache.org/documentation/fuseki2/fuseki-security
and
https://jena.apache.org/documentation/permissions/
On the client side:
https://jena.apache.org/documentation/rdfconnection/
RDFConnectionRemoteBuilder
and pass in an appropriate HttpClient (Apache HttpClient).
Andy
On 19/05/2021 10:36, Bardo Nelgen wrote:
> Hi all,
>
> on good old Fuseki 2.6.0 I could use the IRL of <SERVICE> requests to
> transmit required HTTP basic credentials to access Fuseki.
>
> Obviously this is not possible any longer with the current version – not
> even for localhost.
>
> As using a reverse proxy to restrict access even from the local
> environment to me appears somewhat impractical:
>
> What is the "correct" way to locally control Fuseki access while still
> intending to play by the rules ? :-)
>
> As always, any hint or pointer is highly appreciated.
>
> Best,
> Bardo
>