Ok, I have just seen that the JWT Headers module also verifies the signatures. I would then prioritise my activities in this area less.
Thanks to all for your feedback! Von: Alessio Fabiani <alessio.fabi...@geosolutionsgroup.com> Gesendet: Donnerstag, 26. September 2024 08:40 An: David Blasby <david.bla...@geocat.net> Cc: Francesco Bartoli <francesco.bart...@geobeyond.it>; jody.garn...@gmail.com; Watermeyer, Andreas <andreas.waterme...@its-digital.de>; geoserver-devel@lists.sourceforge.net 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. In my opinion, prioritizing the OAuth2 module functioning as a Resource Server is not essential, as the JWT Token Community module can fully replace its functionality. We should consider investing effort into improving the documentation to clearly present both approaches and their respective scopes, enabling the user community to better understand the differences and determine which solution is most appropriate for their needs. On Thu, Sep 26, 2024 at 2:53 AM David Blasby <david.bla...@geocat.net<mailto:david.bla...@geocat.net>> wrote: 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 -- Regards, Alessio Fabiani == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 331 6233686 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
