Hi, Jim.
I understand everything explained.
And I understand that, in principle, the safety management geoserver is focusing on what the administration (on the one hand, aspects of infrastructure, on the website, and on the other hand, the add and drop of layers, both on the website and in the api interface).
But in the life of the spatial layers, there is a loading time of new layers (many, at first, some, over time), but what remains is the maintenance of the layers that remains until the end of the life of the layer.
To give an example, I add the layer with streets of the city (a layer composed of alphanumeric data of the street, and segments of the block, where I store, for example, a graphics poly-line for each segment, and that, in itself, is the space) element.
Once I did load the layer, then what remains is opening new streets (street segments), changes in vehicular sense, annulments street, etc., all depending on changes in the urban layout.
In these cases, we have, cartographic’s users making those changes (which should have access rules for additions, deletions and modifications of that layer) and the rest of the people, using the layer as a reference, to update other layers, example, traffic lights, trees, bus tours, etc.
Another example: Parcels layer in the city, from making restitution based on a satellite photo or a flight.
There is a initial load, to add all parcels, and then the rest will be divisions of parcels or associations thereof, for real-estate market transactions, operations of demolition and new construction, with the passage of time, or simply changes takes the neighbor on his parcel, lifting a second floor for the son who was to live, etc.
The first part (creating complete parcels layer), an administrator can do with existing tools.
Instead, all the others will make a specialized user, from qgis (desktop edition), bringing the layer, changing some records, and recording them (using the roles that allow you to modify the parcel layer). At another point, a user will seek information about cadastre (parcels and owners).
This user should only have read rights on that layer.
So that I can accomplish this having a direct connection to the base (which has innumerable issues of inefficiency in performance and / or safety). I need to use geoserver (as my only proxy spatial data) so that validates my ldap account through (only validation, like any other municipal application), and then use my rights enabling authorization writing about those layers only the administrator of spatial data, so ordered.
To do this, I need, or have a mechanism through which read my roles (ie, my right to modify the layers, not only create them) or, if not, see what the best solution.
And no use catch the admin password qgis in the environment, since that would put a weak point in the security chain, and security of an application is as strong as its weakest link.
I do not know if I managed to explain.
Thanks for your patient.
jorge infante
···
2016-05-24 12:10 GMT-03:00 Jim Hughes <jnh5y@anonymised.com>:
Hi Jorge,
We are quite happy to help. Overall, GeoServer has lots with security, and I learned most of what I know from reading the docs here (1).
It sounds like you have two tiers of admins: 1) website+GeoServer admins and 2) layer/workspace-only admins. It has been a few months, but I believe I was able to use this tutorial (2) to connect GeoServer to an existing LDAP server.
Additionally, if I remember, I was able to map an LDAP group/role to a GeoServer role. Once that is setup, you could set up a GeoServer role a workspace administrator (see link #3). A workspace admin can add and remove layers within a workspace, but they cannot perform general GeoServer administration.
I’ve done most of this configuration via the GeoServer web UI, so I don’t readily know the answers to some of your questions about what files on disk look like.
Feel free to ask more questions.
Cheers,
Jim
- http://docs.geoserver.org/latest/en/user/security/index.html
- http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html
- http://docs.geoserver.org/latest/en/user/security/layer.html#providing-restricted-administrative-access
On 5/24/2016 5:58 AM, Jorge Infante wrote:
Ok, Jim.
The problem I see with (1) is that if I give the user permissions administration when connected via plug qgis then my problem would be in that same user could access the website, and do things “unwanted”.
We try to restrict the roles for updating processes are performed only by persons authorized to do so in each layer. But, anyway, this gave me an idea.
If I had replicated ldap roles within geoserver (which would keep management within ldap accounts and access permissions to resources within geoserver), each user would be allowed only does what the role that authorizes it. But, of course, it is a mix of authorizations, and do not know whether it is intended.
What I see is that rest.properties, mentions “admin”.
admin that could become a role?
I’m reviewing the matter.
Actually, for me, the solution is that if rest-api delegated authentication functionality in ldap, also made him the authorization.
I think, like, the rest.properties file must exist for match somehow, which is received from the socket with the internal structure of geoserver.
Well, I’m still reviewing the issue, at least, this allows me to meet product issues that otherwise would not have traveled.
Thanks a lot for your patient, again
jorge infante
2016-05-23 9:11 GMT-03:00 Jim Hughes <jnh5y@anonymised.com>:
Hi Jorge,
It sounds like you have two broad tasks: 1) managing layers (while respecting user roles provided by LDAP), and 2) viewing and updating data.
Building on what Andrea mentioned, if LDAP is your role management process, you may need to configure certain LDAP users/groups to have the GeoServer admin role. At the moment, what happens when you log into the GeoServer web UI with your ldap credentials? (I have experimented with this with PKI certs, so that may be a bad question.)
Once security is handled, you might look at the existing QGIS GeoServer plugin (1). It’ll may require some updates based on the LDAP security concerns.
For the second I believe QGIS supports WFS-T for layers registered through WFS. Any layer registration from the GeoServer plugin would likely use this approach, so you might just have to test out making edits and saving them.
Cheers,
Jim
- http://blog.geoserver.org/2015/12/23/geoserver-explorer-plugin-for-qgis/
Source: https://github.com/boundlessgeo/qgis-geoserver-plugin
Docs: http://boundlessgeo.github.io/qgis-geoserver-plugin/index.html
https://plugins.qgis.org/plugins/geoserverexplorer/
On 5/23/2016 7:58 AM, Andrea Aime wrote:
Hi Jorge,
as far as I know (but I have vague memories) the REST API right now demands admin rights to be accessed, and the
rest.properties file does little or nothing in that regard, e.g. one cannot open the REST api to non admin users.
I believe this changed when per workspace services where introduced… if this is confirmed we might want to just
drop the documentation for rest.properties.
I’ve cc’ed Justin, hopefully he’s got a more precise idea of what’s going on here
Cheers
Andrea
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
[https://ad.doubleclick.net/ddm/clk/304595813;131938128;j](https://ad.doubleclick.net/ddm/clk/304595813;131938128;j)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Mon, May 23, 2016 at 1:46 PM, Jorge Infante <joluinfante@anonymised.com> wrote:
Hi.
I’m trying to work in a plugin for qgis, using geoserver as a proxy to spatial layers.
I did check the rest api, but, this interface only works for internal users (like admin/geoserver).
I need connect from the qgis using ldap authentication (like the web application).
I did check if I use the code:
cat=Catalog(“http://”+ip+“:8080/geoserver/rest/”, “jinfant0”, myldappass)
The geoserver code are validating with ldap my user & pass (I did debug to code):
23 may 07:07:56 DEBUG [geoserver.security] - ==========on guavaAuthenticationCacheImpl.put(basic,jinfant0:570d0722c55d10f77243dfd1d8f00e77,org.springframework.security.authentication.UsernamePasswordA
uthenticationToken@anonymised.com: Principal: org.springframework.security.ldap.userdetails.LdapUserDetailsImpl@anonymised.com.: Dn: uid=jinfant0,ou=cuentas,dc=rosario,dc=gov,dc=ar; Username: jinfant0; Password: [
PROTECTED]; Enabled: true; AccountNonExpired: true; CredentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_ADMINISTRATOR, ROLE_CARTOGRAFIA_RO, ROLE_GROUP_ADMIN; Credentials: [PROTECTED]; Authenticated: true; Details: org.geoserver.security.filter.GeoServerWebAuthenticationDetails@anonymised.com: RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities: ROLE_AUTHENTICATED, ROLE_ADMINISTRATOR, ROLE_CARTOGRAFIA_RO, ROLE_GROUP_ADMIN,etc)==========
23 may 07:07:56 DEBUG [geoserver.security] - AuthenticationCache adding new entry for basic, jinfant0:570d0722c55d10f77243dfd1d8f00e77
23 may 07:07:56 DEBUG [geoserver.security] - Cache entries #: 0
23 may 07:07:56 DEBUG [geoserver.security] - AuthenticationCache added new entry for basic, jinfant0:570d0722c55d10f77243dfd1d8f00e77
23 may 07:07:56 DEBUG [geoserver.security] - Cache entries #: 1
But, then, the rest code are using authorization information from rest.properties (RESTAccessRuleDAO.java)
The web app code are using authorization information from layers.properties (DataAccessRuleDAO). On this file, I have:
muni.*.w=ROLE_CARTOGRAFIA_RW
muni.manzanas.r=ROLE_CARTOGRAFIA_RO
mode=HIDE
Then, we have two worlds to access same data.
I’d like, from a plugin on qgis:
- Get list of layers authorized to authenticaded user (using the value for “mode=” in the layers.properties).
- Get layers for read using wfs or wms methods.
- Update elements of layers, using wfs-t methods.
- Another similar things.
I did try using the csw catalog, but, this, don’t user the authentication methods.
My boss don’t enable to use my spatial database open to network. Then, I need use geoserver to access to it.
Can you help me about where I can go with it?
PD: If necessary, I can help with the adequacy of the code.
TIA
jorge infante
rosario - santa fe - argentina
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.