I have been reviewing the security model for the GeoServer and I wanted to confirm that OWS and REST security mechanisms are overlapping - i.e. the following two rules are equivalent:
(1) wfs.*=ROLE_WFS (specified in security.properties file)
(2) /wfs/**;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
Is that correct?
Similarly, are the below two rules equivalent?
(2) wfs.GetFeature=ROLE_WFS (specified in security.properties file)
(3) /wfs?service=wfs&version=2.0.0&request=GetFeature;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
If rule 1=2 and rule 3=4, which security mechanism takes precedence? The OWS or the REST one? Also, would it then be possible to use just a single mechanism (e.g. REST) and make sure that the other one is turned off completely (e.g. OWS one).
Also, as I understand, only the OWS security is exposed through the Web interface of the GeoServer, while the REST security has to be defined directly within a file. Is that correct?
I have never set them up to overlap before In general more specific settings override general settings, so "/wfs/** and GET,POST,PUT,DELETE would be more specific then wfs.*. In your second example version=2.0.0 would be more specific etc…
But I think you may be missing the point rest.properties should be used to lock down REST access?
I have been reviewing the security model for the GeoServer and I wanted to confirm that OWS and REST security mechanisms are overlapping - i.e. the following two rules are equivalent:
(1) wfs.*=ROLE_WFS (specified in security.properties file)
(2) /wfs/**;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
Is that correct?
Similarly, are the below two rules equivalent?
(2) wfs.GetFeature=ROLE_WFS (specified in security.properties file)
(3) /wfs?service=wfs&version=2.0.0&request=GetFeature;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
If rule 1=2 and rule 3=4, which security mechanism takes precedence? The OWS or the REST one? Also, would it then be possible to use just a single mechanism (e.g. REST) and make sure that the other one is turned off completely (e.g. OWS one).
Also, as I understand, only the OWS security is exposed through the Web interface of the GeoServer, while the REST security has to be defined directly within a file. Is that correct?
Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
On Thu, Mar 20, 2014 at 9:49 AM, Jody Garnett <jody.garnett@anonymised.com>wrote:
I have never set them up to overlap before In general more specific
settings override general settings, so "/wfs/** and GET,POST,PUT,DELETE
would be more specific then wfs.*. In your second example version=2.0.0
would be more specific etc...
But I think you may be missing the point rest.properties should be used to
lock down REST access?
Hi,
as far as I remember Justin basically erased support for configurable REST
security as collateral
(probably unintended) result in his work for "workspace specific admin",
now you need to be admin
to access any REST resource, period.
We should probably update the docs...
Cheers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime @geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
I have never set them up to overlap before In general more specific settings override general settings, so "/wfs/** and GET,POST,PUT,DELETE would be more specific then wfs.*. In your second example version=2.0.0 would be more specific etc…
OK, I think I understand. Is that because of the REST security filters are checked first?
But I think you may be missing the point rest.properties should be used to lock down REST access?
I didn’t see anything in the documentation that would prevent me from securing OWS services with the REST security mechanism. I understand that the OWS security mechanism should be used for OWS services - therefore, I wanted to clarify that if it would be possible to use just a single mechanism (e.g. OWS) and make sure that the other one is turned off completely (e.g. REST one). Could you comment on this please?
I have been reviewing the security model for the GeoServer and I wanted to confirm that OWS and REST security mechanisms are overlapping - i.e. the following two rules are equivalent:
(1) wfs.*=ROLE_WFS (specified in security.properties file)
(2) /wfs/**;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
Is that correct?
Similarly, are the below two rules equivalent?
(2) wfs.GetFeature=ROLE_WFS (specified in security.properties file)
(3) /wfs?service=wfs&version=2.0.0&request=GetFeature;GET,POST,PUT,DELETE=ROLE_WFS (specified in rest.properties file)
If rule 1=2 and rule 3=4, which security mechanism takes precedence? The OWS or the REST one? Also, would it then be possible to use just a single mechanism (e.g. REST) and make sure that the other one is turned off completely (e.g. OWS one).
Also, as I understand, only the OWS security is exposed through the Web interface of the GeoServer, while the REST security has to be defined directly within a file. Is that correct?
Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
Does that mean that the entire description of the REST security in the current version of GeoServer documentation is incorrect? I.e. you cannot delegate some admin rights to specific users, who would be also able to create, for example, only workspaces but nothing more?
Hi,
as far as I remember Justin basically erased support for configurable REST security as collateral
(probably unintended) result in his work for “workspace specific admin”, now you need to be admin
to access any REST resource, period.
We should probably update the docs…
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
On Thu, Mar 20, 2014 at 10:40 AM, Maciej Machulak <maciej.machulak@anonymised.com
wrote:
Does that mean that the entire description of the REST security in the
current version of GeoServer documentation is incorrect? I.e. you cannot
delegate some admin rights to specific users, who would be also able to
create, for example, only workspaces but nothing more?
That's my understanding of how things work now, yes.
I know we had a section on configuring and using REST security to allow
read only access to some resources in our
GeoServer training material, and we had to remove it when we upgraded it to
2.4.x because it was not working anymore.
I believe you'll find some mail exchange in the geoserver-devel about it,
if you search in the archives
Cheers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime @geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
That’s my understanding of how things work now, yes.
I know we had a section on configuring and using REST security to allow read only access to some resources in our
GeoServer training material, and we had to remove it when we upgraded it to 2.4.x because it was not working anymore.
I believe you’ll find some mail exchange in the geoserver-devel about it, if you search in the archives
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
Does that mean that the entire description of the REST security in the current version of GeoServer documentation is incorrect? I.e. you cannot delegate some admin rights to specific users, who would be also able to create, for example, only workspaces but nothing more?
That’s my understanding of how things work now, yes.
I know we had a section on configuring and using REST security to allow read only access to some resources in our
GeoServer training material, and we had to remove it when we upgraded it to 2.4.x because it was not working anymore.
I believe you’ll find some mail exchange in the geoserver-devel about it, if you search in the archives
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
Does that mean that the entire description of the REST security in the current version of GeoServer documentation is incorrect? I.e. you cannot delegate some admin rights to specific users, who would be also able to create, for example, only workspaces but nothing more?
In general more specific settings override general settings, so "/wfs/** and GET,POST,PUT,DELETE would be more specific then wfs.*. In your second example version=2.0.0 would be more specific etc…
In general more specific