Layer permissions handling change

[ZakarFin]

Description

Currently map layer permissions are mapped by creating a "unique key" combining the layer type, url and name. This means that if a layer with the same type/url/name is registered again for some reason the permissions are immediately inherited from the previous layer and/or possibly overwritten when the "new" layer is being registered to Oskari.

The proposed change is that permissions are mapped using the layer id (oskari_maplayer.id) so any layer will receive it's own set of permissions and the confusion of inherited permissions no longer happens.

Proposed by: Sami Mäkinen/National Land Survey of Finland

Dependencies

Pretty much everything that has access control for example map layers handling/proxying.

Suggested implementation

The oskari-server/service-permissions module requires changes as well as the database table oskari_resource. Any modules using the service will also need to be updated.

The type of oskari_resource.resource_mapping field should be changed from text to integer. A constraint for oskari_maplayer can't be added as it's used for other types of permissions as well, but the idea is to use the layer id instead of something like 'wmslayer+https://domain.org/geoserver/wms+mylayer'. Flyway migration should be provided to change existing resource_mappings for layers to point to the layer ids.

Also when a layer is removed the permissions for that layer should be removed (as they will otherwise be orphaned information in the database).

Difficulty

• Describe the possible pitfalls of the proposal

The change should be pretty straight forward, but of course requires testing. There might be some exotic use cases for analysis layers that might need some extra tuning to work properly.

Goals

• Describe what this proposal will accomplish

Layer permissions are a bit confusing at the moment and removing layers don't remove permissions for the service since the same set of permissions can be used by another layer. This change simplifies the
permission mapping and adds some housekeeping improvements when layers are removed etc.

It's also a good opportunity to move permissions related classes in service-permissions from fi.mml.portti.* and fi.nls.oskari.* to the org.oskari.* package structure.

[ZakarFin]

This is included in 1.53.