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> 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 <http://www.geobeyond.it>* > *M: +39 333 299 7173* > *S: francesco_bartoli* > > *T: https://twitter.com/geobeyond <https://twitter.com/geobeyond> | > L: https://it.linkedin.com/company/geobeyond > <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 > > >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
