Restrict the creation of remote resources to administrators only by default

[giohappy]

Overview

GeoNode offers several means to add resources obtained from remote services and URLs to its catalogue. This simplifies the integration of documents and datasets from external sources, but requires strong attention to security.

GeoNode implements several security layers to keep insecure resources out of its perimeter, but keeping the surface attack as limited as possible is the best guarantee of safety.

For this reason, we're aiming to introduce a restriction to the catalogue functionality related to remote resources. The plan is to restrict them to administrators only by default. A configuration will allow them to revert to the current behaviour.
The affected features are:

• Remote documents
• Remote datasets (COGs, FGBs, 3dtiles)
• Remote Services (WMS, ArcGIS)

Technical proposal

For the moment, a single global configuration will switch the restriction on/off. Let's call it REGISTERED_USERS_CAN_ADD_REMOTE_RESOURCES for the moment.

This configuration will be read inside the PermissionsHandlerRegistry.get_db_perms_by_user() method and a new synthetic add_remote_resource will be added to the permissions for the current user.

The set of permissions will be returned automatically by the /users API, and the client can use it to handle the frontend tools (like action menus for Remote Services, and the "Add from URL" tab inside the upload pages).

In the future we can decide to handle the settings as a real permission that can be assigned to users and groups.

[cesarbenjamindotnet]

Additionally, I believe it is important and necessary to modify the models related to remote resources. Unlike datasets, documents, and maps—which can have an owner and whose workflow is complete and correct for the owning user—remote resources only allow a URL to be added once. In other words, once a service has been registered with a URL, if another user attempts to register that same URL, they cannot; they must reuse the previously registered URL.

This becomes much more problematic when the resources are private. Furthermore, the harvester assigns ownership based on the owner of the service, which leads to a situation where a remote resource created by user A appears to be owned by user B, simply because user B was the one who initially registered the URL. This causes several inconsistencies in access and permissions. In this case, it is incorrect, since the resource ends up assigned to the user who registered the URL rather than the one who actually published it. This happens because the harvester takes this information from the server, which has an associated owner.

In other words, the URL should not be globally unique but rather unique per user, and when publishing resources, the harvester should determine ownership based on the user who publishes the resource, not on who registered the remote server.