I’ve prototyped some code for making geofence throw a ServiceException when a
LocalWorkspace is set on a request but the user has no access to the workspace
in the context of this service method. This prevents execution of the method
altogether rather than just filtering data. My thinking is that if your
request is in the context of a specific workspace, as indicated by
LocalWorkspace AND you have NO access to ANY layers in that workspace when
executing this method, that I’m not interfering with meaningful processing by
throwing this exception.
This satisfies my goal of blocking execution of the method itself instead of
filtering data.
I’ve done this by adding a call to the following method inside the
GeofenceAccessManager.operationDispatched method…
private void rejectDisallowedOperation(Authentication user, String service,
String request) {
WorkspaceInfo wsInfo = LocalWorkspace.get();
if (wsInfo == null) {
return;
}
String workspace = wsInfo.getName();
RuleFilter ruleFilter = new
RuleFilter(RuleFilter.SpecialFilterType.ANY);
setRuleFilterUserOrRole(user, ruleFilter);
ruleFilter.setInstance(configurationManager.getConfiguration().getInstanceName());
if (service != null) {
if ("*".equals(service)) {
ruleFilter.setService(RuleFilter.SpecialFilterType.ANY);
} else {
ruleFilter.setService(service);
}
} else {
ruleFilter.setService(RuleFilter.SpecialFilterType.DEFAULT);
}
if (request != null) {
if ("*".equals(request)) {
ruleFilter.setRequest(RuleFilter.SpecialFilterType.ANY);
} else {
ruleFilter.setRequest(request);
}
} else {
ruleFilter.setRequest(RuleFilter.SpecialFilterType.DEFAULT);
}
ruleFilter.setWorkspace(workspace);
ruleFilter.setLayer(RuleFilter.SpecialFilterType.ANY);
String sourceAddress = retrieveCallerIpAddress();
if (sourceAddress != null) {
ruleFilter.setSourceAddress(sourceAddress);
} else {
LOGGER.log(Level.WARNING, "No source IP address found");
ruleFilter.setSourceAddress(RuleFilter.SpecialFilterType.DEFAULT);
}
LOGGER.log(Level.FINE, "Local workspace disallow filter: {0}",
ruleFilter);
AccessInfo rule = rules.getAccessInfo(ruleFilter);
if (rule.getGrant().equals(GrantType.DENY)) {
throw new ServiceException("Access denied. Workspace " + workspace
+ " is not accessible.");
}
}
An example of how I use this would be a GF_RULE that specifies a User Role,
Service, Method, Workspace, with access=DENY. With the addition of the code
above this prevents execution of the method altogether IF and only if the
LocalWorkspace is set specifically to this workspace that the user has no
access to.
Would this be an acceptable change to GeofenceAccessManager that I might
contribute via a pull request?
Thanks for your consideration – Walter Stovall
From: Walter Stovall
Sent: Friday, April 01, 2016 4:52 AM
To: 'Andrea Aime'
Cc: [email protected]
Subject: RE: [Geoserver-users] Why does geofence not block access when my rule
says to DENY the method?
Thank you for that detail – it helps a lot. I’m not committed to a solution at
this point.
I agree with you about keeping security issues out of the service code. I’m
just struggling for a solution that works for my requirement to block method
execution by unauthorized users. In this case it is the method I want to
restrict, not the scope of the data.
Your suggestion of a separate set of rules or a flag on the rule is a good one.
I’d like to use geofence for all my security rather than configure separate
code with much of the same information about users and roles, etc. But as it
stands, it apparently will not block a method from executing, so I need to come
up with something.
Thanks for the feedback, Walter
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Andrea Aime
Sent: Thursday, March 31, 2016 1:53 PM
To: Walter Stovall
Cc:
[email protected]<mailto:[email protected]>
Subject: Re: [Geoserver-users] Why does geofence not block access when my rule
says to DENY the method?
On Thu, Mar 31, 2016 at 6:00 PM, Walter Stovall
<[email protected]<mailto:[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.
-------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
