[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
It’s more difficult to know when to give a 401. You can have multiple OAUTH providers at the same time. If one fails, you want it to allow another OAUTH (or a different auth type) to succeed.
In GeoServer, what happens, if all auth mechanisms fail, is you get logged on as Anonymous. This is why you get a layer not found - because the Anonymous user cannot “see” that layer.
I’d have to see what the ogc specifications say about authorization (I don’t think they say much).
We could have all the oauth security providers act as a group and throw a 401 if a request attempts to login via oauth and they all fail - but that’s not, typically, how the GS security system works. Perhaps others who know it more than I could respond…
Hi All,
Sorry for jumping into this discussion despite I’m not part of the GeoServer’s dev team. I’ve seen the blog post from Jody and I’m pretty much interested to contribute on this OIDC/OAuth2 development (btw we have been involved recently by funding some improvements of this module).
From a developer perspective it’s very annoying to receive from WxS endpoints a response different from 401 when the bearer token is not valid (i.e. a token generated for a different OIDC client id instead of the one configured) or maybe it is expired. In fact, if I’m not mistaken, at the moment, GeoServer returns a response with a status code 200 and the message “Layer not found” in the XML.
It’s likely late to raise the interest since the progress I have seen from Andreas but hopefully not at all. I’m available to go ahead somehow with the funding if it’s still reasonable for you.
Regards,
Francesco
—
Kind Regards
Francesco Bartoli | CTO & Owner
-------------------------------------------
GEOBEYOND | Making Geospatial Happen
Via Marchesa Augusta 68, 02040 Vacone (RI)
Italy
W: http://www.geobeyond.it
M: +39 333 299 7173
S: francesco_bartoli
T: https://twitter.com/geobeyond | L: https://it.linkedin.com/company/geobeyond
-----------------------------------------------------------------------------------
This email and any files transmitted with it are confidential. If you have received
this email in error please notify the sender and then delete it immediately.
Please note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Geobeyond Srl.
The recipient should check this email and any attachments for the presence
of viruses. Geobeyond Srl accepts no liability for any damage caused by any virus
transmitted by this email.
Geobeyond Srl may regularly and randomly monitor outgoing and incoming emails
(including the content of them) and other telecommunications on its email
and telecommunications systems. By replying to this email you give your
consent to such monitoring.
*****
Save resources: think before you print.
On 25 Sep 2024, at 21:06, David Blasby via Geoserver-devel <geoserver-devel@lists.sourceforge.net> wrote:
- I also decided to implement the OAuth2 Resource Server role, following Alessio’s response. This is working as well. However, after grepping through the codebase, I found the JWT Headers community module, which I believe has significant functional overlap with the OAuth2 Resource Server role. I assume only one should persist in the long term. I suspect the new Spring implementation involves less code and may be more reliable given its origin (I don’t intend to offend anyone, just I guess). However, if JWT Headers is also used in GeoNetwork, that could be a factor. It might be easier to decide which to keep once the migration is complete and we can compare the final features and codebase. I hope to finish everything within the remaining time. What does the community think?
Hi, Andreas,
The JWT Headers is shared with GeoNetwork and is designed for single signon among multiple applications. It is also designed to be compatible with the Apache OIDC plugin (see docs). It also handles attaching tokens (for robot access). I haven’t looked at the OAuth2 Resource Server, so I cannot comment on the overlap or if it does all of this. The JWT Headers code is very simple and doesn’t really have any dependencies (at least structurally).
Dave
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel