Regarding the OGC Specs: I also don't think there's much to be gained there in terms of security.
Regarding 401: I'll keep that in mind, maybe it's enough to deliver a 401 when the last filter is configured accordingly. But that certainly depends on the project. Von: David Blasby <david.bla...@geocat.net> Gesendet: Donnerstag, 26. September 2024 02:53 An: Francesco Bartoli <francesco.bart...@geobeyond.it> Cc: jody.garn...@gmail.com; Watermeyer, Andreas <andreas.waterme...@its-digital.de>; geoserver-devel@lists.sourceforge.net; Alessio Fabiani <alessio.fabi...@geosolutionsgroup.com> Betreff: Re: [Geoserver-devel] Status Update OAuth2 migration [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. Hi, Francesco, 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... Dave On Wed, Sep 25, 2024 at 3:46 PM Francesco Bartoli <francesco.bart...@geobeyond.it<mailto:francesco.bart...@geobeyond.it>> wrote: 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<mailto: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<mailto:Geoserver-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
