On the question of providing the bearer token as a parameter, would it
be appropriate to just add support for reading the bearer token from
the header and let clients choose which method to use rather than
adding another configuration tickbox option? One use case for the
token as a URL parameter is the oauth2 module implementation of
GeoServer's URLManager, which injects the token into service URLs
included in the OGC catalog documents (GetCapabilities, etc.). This
can enable integration between GeoServer and desktop GIS clients that
otherwise may not support OAuth or configuring custom headers for the
Authorization.
I have a fork that uses Spring's BearerTokenExtractor to extract the
token (see
https://github.com/sjudeng/geoserver/blob/4e0b929ae2c4b945599475744b0aac01881cd37a/src/community/security/oauth2/src/main/java/org/geoserver/security/oauth2/GeoServerOAuthAuthenticationFilter.java#L179).
The implementation in Spring's BearerTokenExtractor checks for the
token in both the header and in the URL parameters (see
https://github.com/spring-projects/spring-security-oauth/blob/master/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/authentication/BearerTokenExtractor.java).
Also it's a bit off topic but the custom fork above is focused on
adding a generic OAuth2 implementation using Spring's
RemoteTokenService directly and I'd be interested in whether you think
it's a good direction for a possible PR or if it would conflict with
any parallel updates being pursued as part of the thread here.
https://github.com/sjudeng/geoserver/tree/default-oauth2
On Wed, Apr 18, 2018 at 7:20 AM, Alessio Fabiani
<alessio.fabi...@geo-solutions.it
<mailto:alessio.fabi...@geo-solutions.it>> wrote:
A tickbox would be a great idea I guess.
Currently on our use cases (GeoNode) we need things to be
stateless, and therefore on that plugin I just ignore anything but
query string access_token. For the gui I rely on JSESSION ID. This
approach does not work for google and github unfortunately.
Regards,
Alessio Fabiani
==GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.==Ing. Alessio Fabiani
@alfa7691Founder/Technical Lead
GeoSolutions S.A.S.Via di Montramito 3/A55054 Massarosa
(LU)Italyphone: +39 0584 962313fax: +39 0584 1660272mob: +39
331
6233686http://www.geo-solutions.ithttp://twitter.com/geosolutions_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.
2018-04-18 10:17 GMT+02:00 Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>>:
We would like to disable passing the bearer token in the URL
(including query string), since this is not recommended, and
in some security standards is not allowed -
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be
passed in page URLs (for example as query string parameters).
Instead, bearer tokens SHOULD be passed in HTTP message
headers or
message bodies for which confidentiality measures are taken.
Browsers, web servers, and other software may not adequately
secure URLs in the browser history, web server logs, and
other
data structures. If bearer tokens are passed in page URLs,
attackers might be able to steal them from the history data,
logs,
or other unsecured locations.
-
https://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3
<https://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3>
But if you need it, perhaps we can create a tickbox to
allow/disallow it?
I do want to make sure that whatever you need to work, still
works, but for that I should be able to reproduce the
behaviour you need. Can you suggest how I can configure it to
let the access_token work without caching?
Regards
Niels
On 17-04-18 17:17, Alessio Fabiani wrote:
Hi Niels,
let's say... the work should be completed. The GUI should get
the access_token from the query string and do not cache the
principal into the JSESSION (which mean SecurityContext).
At this time the situation is a sort of an hybrid. You should
find a compromise or customize ti for you specific use case.
Regards,
Alessio Fabiani
==GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.==Ing. Alessio Fabiani
@alfa7691Founder/Technical Lead
GeoSolutions S.A.S.Via di Montramito 3/A55054 Massarosa
(LU)Italyphone: +39 0584 962313fax: +39 0584 1660272mob:
+39 331
6233686http://www.geo-solutions.ithttp://twitter.com/geosolutions_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.
2018-04-17 17:10 GMT+02:00 Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>>:
Hello Alessio,
Thank you for your answer. I am starting to get it. It
turns out the client was using an older fork of geoserver
and with the most recent commits you did, google and
github do indeed work without the block of code being
commented.
However, I can also reproduce the problem you describe
below with the latest version, despite the block of code
not being commented.
If I use access_token to read the capabilities, I must
close my browser in order to be able to use the other
access_token. Is this normal? Is this intended to work
for google?
Kind Regards
Niels
On 17-04-18 11:12, Alessio Fabiani wrote:
Hello Niels,
sorry for the late response. Unfortunately I had not
much time to deeply inspect the issues you raised and
therefore I'm going to send you some preliminary answers.
1) "Do you have any idea why this could be?" those
services use cookies. On Google and GitHub I had a
similar issue. I fixed that by checking for a session
cookie (see
https://github.com/geoserver/geoserver/blob/master/src/community/security/oauth2-google/src/main/java/org/geoserver/security/oauth2/GoogleOAuthAuthenticationFilter.java#L30
<https://github.com/geoserver/geoserver/blob/master/src/community/security/oauth2-google/src/main/java/org/geoserver/security/oauth2/GoogleOAuthAuthenticationFilter.java#L30>)
2) "How I can reproduce the problem". Generate two
different access_tokens associated to different roles.
Assign different resources to the roles. Then open a
browser window and login into the GUI with one of them.
Now try to do a GetCapabilities request by passing the
access_token as query parameter. If the session is not
cached, you should be able to see different resources by
simply changing the access_token. Otherwise you will
need to close the browser session (or cleanup the cookies).
3) "why I get the names of java classes showing up next
to the log-in form". This should happen only when
running on Eclipse. Try to build the WAR. You should be
able to get the icons. In general the issue should be
related to the fact that Spring is not able to stream
the icon resource.
Sorry for the quick responses. Hope that those can be
still be useful in order to allow you making further
testing.
Let me know if you have a specific use case I should try
to reproduce somehow and feel free to propose a patch
for the community module.
Regards,
Alessio Fabiani
==GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.==Ing.
Alessio Fabiani
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
@alfa7691Founder/Technical Lead
GeoSolutions S.A.S.Via di Montramito 3/A
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>55054
Massarosa
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
(LU)Italyphone: +39 0584 962313fax: +39 0584
1660272mob: +39 331
6233686http://www.geo-solutions.ithttp://twitter.com/geosolutions_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.
2018-04-13 13:48 GMT+02:00 Niels Charlier
<ni...@scitus.be <mailto:ni...@scitus.be>>:
Hi Alessio,
Thanks for your answer. It is strange, but I need to
comment out this code for it to work at all, just
the same as my client. Otherwise geoserver does not
log me in (although the logging in process on
google/github works fine). Do you have any idea why
this could be?
Also, can you give me an example of how I can
reproduce the problem you have without that block of
code, so I can figure out a solution that works for
both of us.
Finally, do you know why I get the names of java
classes showing up next to the log-in form? (see
attached photo)
Thanks in advance!
Kind Regards
Niels
On 09-04-18 12:49, Alessio Fabiani wrote:
Hi Niels,
as far as I remember, this causes cache issues with
requests.
Basically if you are logged in on GeoServer GUI and
you want to make OWS requests passing the
access_token, the service will always get the
in-memory Principal.
The correct way to handle this would be to allow
the GUI to get the "access_token" query parameter
also from the address... not that easy using wicket
unfortunately.
Regards,
Alessio Fabiani
==GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more
information.==Ing. Alessio Fabiani
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
@alfa7691<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>Founder/Technical
Lead
GeoSolutions S.A.S.Via di Montramito 3/A
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>55054
Massarosa
<https://maps.google.com/?q=Via+di+Montramito+3/A+%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
(LU)Italyphone: +39 0584 962313fax: +39 0584
1660272mob: +39 331
6233686http://www.geo-solutions.ithttp://twitter.com/geosolutions_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.
2018-04-09 11:50 GMT+02:00 Niels Charlier
<ni...@scitus.be <mailto:ni...@scitus.be>>:
Hello Alessio,
I have a question about code in the OAuth2
community module which you have written.
What was the reason for this block of code:
https://github.com/geoserver/geoserver/blob/master/src/community/security/oauth2/src/main/java/org/geoserver/security/oauth2/GeoServerOAuthAuthenticationFilter.java#L130
<https://github.com/geoserver/geoserver/blob/master/src/community/security/oauth2/src/main/java/org/geoserver/security/oauth2/GeoServerOAuthAuthenticationFilter.java#L130>
that removes the access token and prevents the
use of session cookies after establishing an
OAuth2 based Session for the UI.
We had to comment on this block of code for
now. Can we make this a configurable option
perhaps?
Thanks in advance for your answer!
Kind Regards
Niels
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>
