https://osgeo-org.atlassian.net/browse/GEOS-11421 *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS
*Gabriel Roldán* Geospatial Developer On Thu, May 30, 2024 at 12:32 PM Gabriel Roldan < gabriel.rol...@camptocamp.com> wrote: > Okay, I'll create a ticket then. > > Given we can implement without breaking API I guess a GSIP wouldn't be > necessary? > > Questions to Geofence experts: > > An AdminRule's grant type can be ADMIN or USER. > The semantics for ADMIN are pretty clear, but I'm having trouble > determining if USER has any practical implications. > May it be that an AdminRule with USER grant should give read-only access > to the workspace and its nested objects? > > Also, thinking forward about this proposal, I'm wondering what'd be the > right way to handle AdminRule and Rule collisions in terms of data access. > Let's say a user has ADMIN rights to a workspace, but the data-access > Rules don't let him see that workspace. > * Does it mean the user can admin (and hence see) the workspace and its > nested objects for admin purposes, but can't do any service requests? > (GetMap, etc) > * Should the workspace ADMIN rule override the data access rules and let > him also access the workspace/layers? > > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Gabriel Roldán* > Geospatial Developer > > > > On Thu, May 30, 2024 at 12:13 PM Jody Garnett <jody.garn...@gmail.com> > wrote: > >> Nice timing Gabe, >> >> I actually ran into this disconnect last week also (testing the geocat >> bridge plugin which uses the REST API). It would be nice to provide access >> for automation limited to specific workspaces. >> -- >> Jody Garnett >> >> >> On May 30, 2024 at 8:08:51 AM, Gabriel Roldan < >> gabriel.rol...@camptocamp.com> wrote: >> >>> Hey all, >>> >>> The mentioning of unmatched webui/rest functionality for URL checks in >>> the other thread reminded me I wanted to bring up this topic too. >>> >>> Thing is, ResourceAccessManager (default, geofence, geoserver-acl) >>> allows defining if a user is a workspace administrator. If so, the webui >>> will allow him to administer them, limiting the listed catalog objects >>> accordingly. >>> >>> But the matching functionality is not available through the REST API. It >>> would make sense, IMHO, that if a user has admin rights to a workspace, it >>> can administer it both through the webui and the rest api, allowing access >>> to the following paths: >>> >>> /rest/workspaces/ (limiting the visibility to the adminable workspaces) >>> /rest/workspaces/<workspace> >>> /rest/workspaces/<workspace>/** >>> /rest/resource/workspaces/ (limiting the visibility to the adminable >>> workspaces) >>> /rest/resource/workspaces/<workspace>/** >>> >>> This can be implemented with an additional, ResourceAcessManager-backed >>> AccessDecisionVoter in GeoServerSecurityInterceptorFilter, so that instead >>> of fully overriding the security/rest.properties config file, it'd >>> complement it. >>> >>> Does this make sense? >>> >>> *camptocamp* >>> INNOVATIVE SOLUTIONS >>> BY OPEN SOURCE EXPERTS >>> >>> *Gabriel Roldán* >>> Geospatial Developer >>> >>> _______________________________________________ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
