We are running GeoServer behind a HTTP security proxy which provides both user authentication and user group membership information (via HTTP Headers).
Is it possible to somehow pass the user groups into GeoServer for use by Security subsystem, against a suitably configured Role Service?
We are happy to write a custom filter to extract the HTTP headers - it’s just not clear if there’s a place to put the group information so that it can be utilized by the Security subsystem.
Thanks, Mauro. We are aware of the ability to pass roles as well as the user. That’s certainly a nice facility to have. Unfortunately in the context we are in it is non-trivial to map the supplied group to roles (for various reasons, one of which is that the filter would essentially need to implement its own Role Service to access the roles defined in the GeoServer environment).
We were hoping that if there was a way to pass groups as well as the user to the Security Subsystem, we could leave the work of computing the group-role-layer query to it.
Instead, we may look at implementing a ResourceAccessManager plugin that can access the Authorization mechanism that is already in place.
Martin
···
On Wed, Feb 24, 2016 at 12:19 AM, Mauro Bartolomeoli <maurobartolomeoli@anonymised.com> wrote:
Hi Martin,
2016-02-24 2:03 GMT+01:00 Martin Davis <mtnclimb@anonymised.com>:
We are running GeoServer behind a HTTP security proxy which provides both user authentication and user group membership information (via HTTP Headers).
Is it possible to somehow pass the user groups into GeoServer for use by Security subsystem, against a suitably configured Role Service?
What you can currently do is use the HTTP Header Authentication Filter to extract both the username and a list of roles (not groups) from two distinct HTTP headers.
To accomplish that you need to choose Request Header as the Role Source in the filter configuration.
From related help: If the role source is Request header, the name of the HTTP header attribute has to be specified.The content of this attribute are the roles of the principal. The default role delimiter is the semicolon ;.GeoServer accepts the sent roles without verification.
Since roles are used for authorization purposes, probably it’s not an issue mapping your groups to GeoServer roles.
If you need something more flexible, some customization of this filter is needed.
Thanks for the suggestion. We did briefly consider looking at a UserGroupService implementation.
It turned out that the client wants to be able to use the Geoserver security subsystem to maintain and enforce the layer-role policies (i.e. in the layers.properties file). So that ruled out the use of a ResourceAccessManager extension.
In the end we’re going with a custom servlet Filter which will use the enterprise directory service to determine the roles for the user provided in the request header. The roles will be injected into a request header for use by the HTTP Header Authentication module [1][2] with a Role Source “Request Header”.
If you see any issues with this concept please advise!
[1] http://docs.geoserver.org/stable/en/user/security/tutorials/httpheaderproxy/index.html#configure-the-http-header-filter
[2] http://docs.geoserver.org/stable/en/user/security/usergrouprole/rolesource.html#using-an-http-header-attribute
PS it wasn’t totally clear to me from the docs above how to set the header attribute name for roles. It would be good to mention in [1] that the role header name is entered by choosing “Request Header” under Role source, and also be a bit more explicit about the configuration UI in [2]. (I know, I know - make a PR for this!)
···
On Thu, Feb 25, 2016 at 12:51 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com07…> wrote:
Hi Martin,
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
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.
2016-02-24 18:22 GMT+01:00 Martin Davis <mtnclimb@anonymised.com>:
Thanks, Mauro. We are aware of the ability to pass roles as well as the user. That’s certainly a nice facility to have. Unfortunately in the context we are in it is non-trivial to map the supplied group to roles (for various reasons, one of which is that the filter would essentially need to implement its own Role Service to access the roles defined in the GeoServer environment).
Unfortunately you need a UserGroupService to assign groups to users. You could implement a custom one, that gets groups from an header (the UserGroupService should be able to access current request headers through the Dispatcher.REQUEST ThreadLocal).
Regards,
Mauro Bartolomeoli