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: geoserver-users@lists.sourceforge.net
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: andrea.aime@…84… [mailto:andrea.aime@…84…] On Behalf Of Andrea Aime
Sent: Thursday, March 31, 2016 1:53 PM
To: Walter Stovall
Cc: geoserver-users@lists.sourceforge.net
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 <walter.stovall@…7262…> 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//ows?..
-
Layer specific, which are only answering considering a single layer or layer group, referred via geoserver///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://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.