You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Jeffrey C. Witt" <je...@gmail.com> on 2018/07/17 10:20:58 UTC
public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
I was reading this security documentation (
https://jena.apache.org/documentation/fuseki2/fuseki-security.html) today
and had a small question.
Basically, I would like be able to make PUT, POST, DELETE requests from
localhost, while restricting public access to the SPARQL endpoint (requests
NOT originating from localhost) to GET only requests.
My question is whether according to the above documentation that is the
default configuration.
The docs say:
"In its default configuration, SPARQL endpoints are open to the public but
administrative functions are limited to localhost."
More concretely my question is, are PUT, POST, and DELETE requests
considered "administrative" functions?
Thanks
jw
Re: public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
Posted by Claude Warren <cl...@xenei.com>.
You can also use the permissions system to enforce full CRUD restrictions
if needed. Though it does take a bit more work.
On Thu, Jul 19, 2018 at 2:57 PM, ajs6f <aj...@apache.org> wrote:
> Keep in mind that you can wire up your endpoints just as you like:
>
> https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
>
> including multiple endpoints for any given service and so on.
>
> ajs6f
>
> > On Jul 19, 2018, at 8:08 AM, Andy Seaborne <an...@apache.org> wrote:
> >
> >
> >
> > On 18/07/18 18:53, Dan Pritts wrote:
> >> I use shiro.ini as follows. I did this so I could have our monitoring
> system do queries, while our primary consumer software had full
> privileges. I presume, but honestly don't know for sure, that the
> /foo/query URL allows queries only.
> >
> > It does - if you use a service name /query (and the config does not wire
> that to.say, update :-) then the request goes to the query action handler
> which only groks SPARQL queries and can't go to anything else.
> >
> > Andy
> >
> >> Note that the write_user needs to have both reader_role and writer_role.
> >> # Licensed under the terms of http://www.apache.org/
> licenses/LICENSE-2.0
> >> [main]
> >> # we aren't using TLS because we are proxied by apache which handles
> that for us
> >> ssl.enabled = false
> >> # a simple sha256 is adequate for this internal-only usage
> >> # to do better, look at https://shiro.apache.org/
> command-line-hasher.html
> >> credentialsMatcher = org.apache.shiro.authc.credential.
> Sha256CredentialsMatcher
> >> #iniRealm=org.apache.shiro.realm.text.IniRealm
> >> iniRealm.credentialsMatcher = $credentialsMatcher
> >> [users]
> >> # adding users here implicitly adds "iniRealm =
> org.apache.shiro.realm.text.IniRealm"
> >> # to get the sha hash:
> >> # echo -n "passwordhere" | sha256sum # but watch out, the password
> is in your shell history now!
> >> # the -n is important, otherwise you'll get a newline.
> >> # or get the Shiro Hasher tool
> >> write_user=shasumhere,reader_role,writer_role
> >> read_user=shasumhere,reader_role
> >> # roles that you implicitly created in the users section don't
> necessarily need to be listed here
> >> [roles]
> >> # this is a "first match wins" config.
> >> [urls]
> >> ## Control functions open to anyone
> >> /$/stats = anon
> >> /$/server = anon
> >> /$/ping = anon
> >> /fcrepo/query = authcBasic, roles[reader_role]
> >> /** = authcBasic, roles[writer_role]
> >> Andy Seaborne wrote on 7/17/18 12:32 PM:
> >>> Hi there,
> >>>
> >>> > More concretely my question is, are PUT, POST, and DELETE requests
> >>> > considered "administrative" functions?
> >>>
> >>> Admin operations are HTTP requests to the UI - the URLs start "/$/"
> not the graph management PUT, POST, and DELETE requests of SPARQL Graph
> Store Protocol (and the dataset URL also respects plain REST PUT, POST).
> >>>
> >>> SPARQL Query can be over POST - large queries can be over the
> practical limits of HTTP GET and POST allows a query of any size to be set.
> >>>
> >>> If you want detailed control, you can do some configuration by using
> the built-in Apache Shiro but it can be easier to put the Fuseki server
> behind a reverse proxy (Apache httpd, nginx, ...) because these systems
> have more detailed and sophisticated permissions control systems including
> load control.
> >>>
> >>> Or run in Apache Tomcat as a WAR and use Tomcat controls.
> >>>
> >>>
> >>> Andy
> >>>
> >>> Apache Shiro + REST
> >>> https://stackoverflow.com/questions/41918916/apache-
> shiro-http-method-level-permission
> >>>
> >>> On 17/07/18 11:20, Jeffrey C. Witt wrote:
> >>>> I was reading this security documentation (
> >>>> https://jena.apache.org/documentation/fuseki2/fuseki-security.html)
> today
> >>>> and had a small question.
> >>>>
> >>>> Basically, I would like be able to make PUT, POST, DELETE requests
> from
> >>>> localhost, while restricting public access to the SPARQL endpoint
> (requests
> >>>> NOT originating from localhost) to GET only requests.
> >>>>
> >>>> My question is whether according to the above documentation that is
> the
> >>>> default configuration.
> >>>>
> >>>> The docs say:
> >>>>
> >>>> "In its default configuration, SPARQL endpoints are open to the
> public but
> >>>> administrative functions are limited to localhost."
> >>>>
> >>>> More concretely my question is, are PUT, POST, and DELETE requests
> >>>> considered "administrative" functions?
> >>>>
> >>>> Thanks
> >>>> jw
> >>>>
> >> --
> >> Dan Pritts
> >> ICPSR Computing & Network Services
> >> University of Michigan
> >> <https://www.postbox-inc.com>
>
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
Posted by ajs6f <aj...@apache.org>.
Keep in mind that you can wire up your endpoints just as you like:
https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
including multiple endpoints for any given service and so on.
ajs6f
> On Jul 19, 2018, at 8:08 AM, Andy Seaborne <an...@apache.org> wrote:
>
>
>
> On 18/07/18 18:53, Dan Pritts wrote:
>> I use shiro.ini as follows. I did this so I could have our monitoring system do queries, while our primary consumer software had full privileges. I presume, but honestly don't know for sure, that the /foo/query URL allows queries only.
>
> It does - if you use a service name /query (and the config does not wire that to.say, update :-) then the request goes to the query action handler which only groks SPARQL queries and can't go to anything else.
>
> Andy
>
>> Note that the write_user needs to have both reader_role and writer_role.
>> # Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0
>> [main]
>> # we aren't using TLS because we are proxied by apache which handles that for us
>> ssl.enabled = false
>> # a simple sha256 is adequate for this internal-only usage
>> # to do better, look at https://shiro.apache.org/command-line-hasher.html
>> credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
>> #iniRealm=org.apache.shiro.realm.text.IniRealm
>> iniRealm.credentialsMatcher = $credentialsMatcher
>> [users]
>> # adding users here implicitly adds "iniRealm = org.apache.shiro.realm.text.IniRealm"
>> # to get the sha hash:
>> # echo -n "passwordhere" | sha256sum # but watch out, the password is in your shell history now!
>> # the -n is important, otherwise you'll get a newline.
>> # or get the Shiro Hasher tool
>> write_user=shasumhere,reader_role,writer_role
>> read_user=shasumhere,reader_role
>> # roles that you implicitly created in the users section don't necessarily need to be listed here
>> [roles]
>> # this is a "first match wins" config.
>> [urls]
>> ## Control functions open to anyone
>> /$/stats = anon
>> /$/server = anon
>> /$/ping = anon
>> /fcrepo/query = authcBasic, roles[reader_role]
>> /** = authcBasic, roles[writer_role]
>> Andy Seaborne wrote on 7/17/18 12:32 PM:
>>> Hi there,
>>>
>>> > More concretely my question is, are PUT, POST, and DELETE requests
>>> > considered "administrative" functions?
>>>
>>> Admin operations are HTTP requests to the UI - the URLs start "/$/" not the graph management PUT, POST, and DELETE requests of SPARQL Graph Store Protocol (and the dataset URL also respects plain REST PUT, POST).
>>>
>>> SPARQL Query can be over POST - large queries can be over the practical limits of HTTP GET and POST allows a query of any size to be set.
>>>
>>> If you want detailed control, you can do some configuration by using the built-in Apache Shiro but it can be easier to put the Fuseki server behind a reverse proxy (Apache httpd, nginx, ...) because these systems have more detailed and sophisticated permissions control systems including load control.
>>>
>>> Or run in Apache Tomcat as a WAR and use Tomcat controls.
>>>
>>>
>>> Andy
>>>
>>> Apache Shiro + REST
>>> https://stackoverflow.com/questions/41918916/apache-shiro-http-method-level-permission
>>>
>>> On 17/07/18 11:20, Jeffrey C. Witt wrote:
>>>> I was reading this security documentation (
>>>> https://jena.apache.org/documentation/fuseki2/fuseki-security.html) today
>>>> and had a small question.
>>>>
>>>> Basically, I would like be able to make PUT, POST, DELETE requests from
>>>> localhost, while restricting public access to the SPARQL endpoint (requests
>>>> NOT originating from localhost) to GET only requests.
>>>>
>>>> My question is whether according to the above documentation that is the
>>>> default configuration.
>>>>
>>>> The docs say:
>>>>
>>>> "In its default configuration, SPARQL endpoints are open to the public but
>>>> administrative functions are limited to localhost."
>>>>
>>>> More concretely my question is, are PUT, POST, and DELETE requests
>>>> considered "administrative" functions?
>>>>
>>>> Thanks
>>>> jw
>>>>
>> --
>> Dan Pritts
>> ICPSR Computing & Network Services
>> University of Michigan
>> <https://www.postbox-inc.com>
Re: public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
Posted by Andy Seaborne <an...@apache.org>.
On 18/07/18 18:53, Dan Pritts wrote:
> I use shiro.ini as follows. I did this so I could have our monitoring
> system do queries, while our primary consumer software had full
> privileges. I presume, but honestly don't know for sure, that the
> /foo/query URL allows queries only.
It does - if you use a service name /query (and the config does not wire
that to.say, update :-) then the request goes to the query action
handler which only groks SPARQL queries and can't go to anything else.
Andy
>
> Note that the write_user needs to have both reader_role and writer_role.
>
>
>
> # Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0
>
> [main]
> # we aren't using TLS because we are proxied by apache which handles
> that for us
> ssl.enabled = false
>
> # a simple sha256 is adequate for this internal-only usage
> # to do better, look at https://shiro.apache.org/command-line-hasher.html
> credentialsMatcher =
> org.apache.shiro.authc.credential.Sha256CredentialsMatcher
>
> #iniRealm=org.apache.shiro.realm.text.IniRealm
> iniRealm.credentialsMatcher = $credentialsMatcher
>
> [users]
> # adding users here implicitly adds "iniRealm =
> org.apache.shiro.realm.text.IniRealm"
>
> # to get the sha hash:
> # echo -n "passwordhere" | sha256sum # but watch out, the password
> is in your shell history now!
> # the -n is important, otherwise you'll get a newline.
> # or get the Shiro Hasher tool
>
> write_user=shasumhere,reader_role,writer_role
> read_user=shasumhere,reader_role
>
> # roles that you implicitly created in the users section don't
> necessarily need to be listed here
> [roles]
>
> # this is a "first match wins" config.
> [urls]
>
> ## Control functions open to anyone
> /$/stats = anon
> /$/server = anon
> /$/ping = anon
>
> /fcrepo/query = authcBasic, roles[reader_role]
> /** = authcBasic, roles[writer_role]
>
> Andy Seaborne wrote on 7/17/18 12:32 PM:
>> Hi there,
>>
>> > More concretely my question is, are PUT, POST, and DELETE requests
>> > considered "administrative" functions?
>>
>> Admin operations are HTTP requests to the UI - the URLs start "/$/"
>> not the graph management PUT, POST, and DELETE requests of SPARQL
>> Graph Store Protocol (and the dataset URL also respects plain REST
>> PUT, POST).
>>
>> SPARQL Query can be over POST - large queries can be over the
>> practical limits of HTTP GET and POST allows a query of any size to be
>> set.
>>
>> If you want detailed control, you can do some configuration by using
>> the built-in Apache Shiro but it can be easier to put the Fuseki
>> server behind a reverse proxy (Apache httpd, nginx, ...) because these
>> systems have more detailed and sophisticated permissions control
>> systems including load control.
>>
>> Or run in Apache Tomcat as a WAR and use Tomcat controls.
>>
>>
>> Andy
>>
>> Apache Shiro + REST
>> https://stackoverflow.com/questions/41918916/apache-shiro-http-method-level-permission
>>
>>
>> On 17/07/18 11:20, Jeffrey C. Witt wrote:
>>> I was reading this security documentation (
>>> https://jena.apache.org/documentation/fuseki2/fuseki-security.html)
>>> today
>>> and had a small question.
>>>
>>> Basically, I would like be able to make PUT, POST, DELETE requests from
>>> localhost, while restricting public access to the SPARQL endpoint
>>> (requests
>>> NOT originating from localhost) to GET only requests.
>>>
>>> My question is whether according to the above documentation that is the
>>> default configuration.
>>>
>>> The docs say:
>>>
>>> "In its default configuration, SPARQL endpoints are open to the
>>> public but
>>> administrative functions are limited to localhost."
>>>
>>> More concretely my question is, are PUT, POST, and DELETE requests
>>> considered "administrative" functions?
>>>
>>> Thanks
>>> jw
>>>
>
> --
> Dan Pritts
> ICPSR Computing & Network Services
> University of Michigan
> <https://www.postbox-inc.com>
Re: public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
Posted by Dan Pritts <da...@umich.edu>.
I use shiro.ini as follows. I did this so I could have our monitoring
system do queries, while our primary consumer software had full
privileges. I presume, but honestly don't know for sure, that the
/foo/query URL allows queries only.
Note that the write_user needs to have both reader_role and writer_role.
# Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0
[main]
# we aren't using TLS because we are proxied by apache which handles
that for us
ssl.enabled = false
# a simple sha256 is adequate for this internal-only usage
# to do better, look at https://shiro.apache.org/command-line-hasher.html
credentialsMatcher =
org.apache.shiro.authc.credential.Sha256CredentialsMatcher
#iniRealm=org.apache.shiro.realm.text.IniRealm
iniRealm.credentialsMatcher = $credentialsMatcher
[users]
# adding users here implicitly adds "iniRealm =
org.apache.shiro.realm.text.IniRealm"
# to get the sha hash:
# echo -n "passwordhere" | sha256sum # but watch out, the password
is in your shell history now!
# the -n is important, otherwise you'll get a newline.
# or get the Shiro Hasher tool
write_user=shasumhere,reader_role,writer_role
read_user=shasumhere,reader_role
# roles that you implicitly created in the users section don't
necessarily need to be listed here
[roles]
# this is a "first match wins" config.
[urls]
## Control functions open to anyone
/$/stats = anon
/$/server = anon
/$/ping = anon
/fcrepo/query = authcBasic, roles[reader_role]
/** = authcBasic, roles[writer_role]
Andy Seaborne wrote on 7/17/18 12:32 PM:
> Hi there,
>
> > More concretely my question is, are PUT, POST, and DELETE requests
> > considered "administrative" functions?
>
> Admin operations are HTTP requests to the UI - the URLs start "/$/"
> not the graph management PUT, POST, and DELETE requests of SPARQL
> Graph Store Protocol (and the dataset URL also respects plain REST
> PUT, POST).
>
> SPARQL Query can be over POST - large queries can be over the
> practical limits of HTTP GET and POST allows a query of any size to be
> set.
>
> If you want detailed control, you can do some configuration by using
> the built-in Apache Shiro but it can be easier to put the Fuseki
> server behind a reverse proxy (Apache httpd, nginx, ...) because these
> systems have more detailed and sophisticated permissions control
> systems including load control.
>
> Or run in Apache Tomcat as a WAR and use Tomcat controls.
>
>
> Andy
>
> Apache Shiro + REST
> https://stackoverflow.com/questions/41918916/apache-shiro-http-method-level-permission
>
>
> On 17/07/18 11:20, Jeffrey C. Witt wrote:
>> I was reading this security documentation (
>> https://jena.apache.org/documentation/fuseki2/fuseki-security.html)
>> today
>> and had a small question.
>>
>> Basically, I would like be able to make PUT, POST, DELETE requests from
>> localhost, while restricting public access to the SPARQL endpoint
>> (requests
>> NOT originating from localhost) to GET only requests.
>>
>> My question is whether according to the above documentation that is the
>> default configuration.
>>
>> The docs say:
>>
>> "In its default configuration, SPARQL endpoints are open to the
>> public but
>> administrative functions are limited to localhost."
>>
>> More concretely my question is, are PUT, POST, and DELETE requests
>> considered "administrative" functions?
>>
>> Thanks
>> jw
>>
--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan
<https://www.postbox-inc.com>
Re: public SPARQL GET requests, while restricting PUT, POST, DELETE
requests to localhost
Posted by Andy Seaborne <an...@apache.org>.
Hi there,
> More concretely my question is, are PUT, POST, and DELETE requests
> considered "administrative" functions?
Admin operations are HTTP requests to the UI - the URLs start "/$/" not
the graph management PUT, POST, and DELETE requests of SPARQL Graph
Store Protocol (and the dataset URL also respects plain REST PUT, POST).
SPARQL Query can be over POST - large queries can be over the practical
limits of HTTP GET and POST allows a query of any size to be set.
If you want detailed control, you can do some configuration by using the
built-in Apache Shiro but it can be easier to put the Fuseki server
behind a reverse proxy (Apache httpd, nginx, ...) because these systems
have more detailed and sophisticated permissions control systems
including load control.
Or run in Apache Tomcat as a WAR and use Tomcat controls.
Andy
Apache Shiro + REST
https://stackoverflow.com/questions/41918916/apache-shiro-http-method-level-permission
On 17/07/18 11:20, Jeffrey C. Witt wrote:
> I was reading this security documentation (
> https://jena.apache.org/documentation/fuseki2/fuseki-security.html) today
> and had a small question.
>
> Basically, I would like be able to make PUT, POST, DELETE requests from
> localhost, while restricting public access to the SPARQL endpoint (requests
> NOT originating from localhost) to GET only requests.
>
> My question is whether according to the above documentation that is the
> default configuration.
>
> The docs say:
>
> "In its default configuration, SPARQL endpoints are open to the public but
> administrative functions are limited to localhost."
>
> More concretely my question is, are PUT, POST, and DELETE requests
> considered "administrative" functions?
>
> Thanks
> jw
>