On Thu, Mar 31, 2016 at 6:00 PM, Walter Stovall <[email protected]>
wrote:
> Thanks. That works for most things. But in my case I have a custom
> service that creates new workspaces and layers. I only want authorized
> users to execute this service method.
>
>
>
> As I see it, if the rule specifies the Service and Request but not the
> workspace or layer, the method should be blocked since it doesn’t allow
> access to anything.
>
I'm afraid this would lead to much confusion when you factor in all the
GeoServer features.
The type of rule that you're referring to is a simple enough case, but it
opens a precedent that will muddy the waters for worskpace and layer
specific services.
In GeoServer one can use three types of OGC services:
* Globals, the ones you where thinking about, referred via
/geoserver/ows?...
* Workspace specific, which are only answering considering resource in a
particular worksace, referred via geoserver/<wsname>/ows?...
* Layer specific, which are only answering considering a single layer or
layer group, referred via geoserver/<wsname>/<layerOrGroupName>/ows?...
So a rule with ws=null and layer=null seems clear enough, really does not
allow any access.
But what about a rule with a workspace specified, but no layer? Do I treat
it as data filtering for global services, but deying full service access on
the workspace and layer specific services?
And the same goes for rules that specify both workspace and layer.
Long story short, if we follow the approach your suggesting the existing
would have unintended consequences on the workspace and layer specific
services,
that the rule editor might not be even aware of.
It would be better to have a separate set of rules, or a flag in the rules,
stating that the rule is not meant to limit data access (which is the one
and only
reason to use a ResourceAccessManager), but to apply a service level
restriction (which is better implemented as a DispatcherCallback instead,
that
can block the request even before it gets into the service code).
So, this would make it a design change, not a simple "fix" in the
ResourceAccessManager implementation.
It seems you are proceeding with your own custom solution (which is a no-no
in GeoServer, services must never be security aware, that would
complicate their code too much and make maintenance and evolution harder),
but I shared the above approach anyways, just in case others have a need
for service level security with GeoFence :-)
Cheers
Andrea
--
==
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.
-------------------------------------------------------
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
