-
Notifications
You must be signed in to change notification settings - Fork 0
GNIP 1 Securing GeoNode Proxies
Rather than simply proxying the REST API in Django, we should provide a smarter service which is able to enforce the restrictions implied by the layer permissions in GeoNode.
David Winslow
TBD.
Under Discussion
GeoNode aspires to provide a richer security model than GeoServer, allowing users to upload and manage data while protecting them from accidental or malicious misconfiguration by others. In GeoNode we currently delegate many administrative actions to GeoServer's REST API, and suffer from the lack of fine-grained security in that service. Implementing deeper inspection of the REST requests that come into GeoNode would allow us to better implement GeoNode's security model.
The problems under discussion here arise from REST requests being passed directly through the Django application to GeoServer, without any consideration given to information that Django has but GeoServer is not capable of applying. As an example of such information, it is currently impossible to prevent authenticated users from modifying styles on any layer in the site. Implementing deeper inspection in Django would allow us to implement restrictions such as "only the owner and administrators of a layer may modify or replace its default style."
This step would involve a review of all requests made by GXP components in GeoNode and identification of the REST API operations that are currently used. One way to do this could be to simply remove the 'geonode.proxy.views:geoserver' view from the application and test the site to see which features fail.
In order to avoid losing functionality, the removed REST APIs will need to be replaced with Django endpoints that analyze the requests and cross-reference them with the Django user and permissions database before passing them along. For example, a request to the /styles/ endpoint could verify that the authenticated user has "edit" permissions for all layers that use the style, and that either the user is an administrator for those layers or the style is not the default one.
One design decision to be made here is whether or not to attempt to duplicate the GeoServer REST API in Django. If we can produce a faithful reimplementation of the GeoServer REST API then the GXP components that expect it may not even need to be modified to take advantage of it. However, the REST API is not rigorously documented and is subject to (minor) change without warning, so implementing and maintaining a faithful reimplementation, even of the subset of the REST API that we actually use, may be problematic. A lighter API designed specifically for GeoNode's needs may be simpler to maintain, but would require custom GXP/GeoExt development.
One fairly obvious alternative implementation would be to improve GeoServer's security system, rather than wrapping it in GeoNode code. However, this is a technically daunting task, and the code would be difficult for GeoNode's Python developers to work with. So I think it will be faster and easier to maintain a set of wrapper proxies than to implement the security improvements on the GeoServer side. This arrangement does not open up security vulnerabilities to attackers bypassing the proxy, since we can simply not grant administrative privileges at all to users who are not actually administrators of the site, similar to how Django user accounts do not have corresponding user accounts in the PostgreSQL database for a GeoNode site.
No feedback yet.
No votes yet.