Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
–
Jody Garnett
Hi Jody,
Can I list you and your employer as a party working in this blog post?
Yes, that’s fine
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Donnerstag, 18. Juli 2024 18:24
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
–
Jody Garnett
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
–
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
–
Jody Garnett
Hi Jody,
I am back now. Please let me know when we can discuss how to continue with this. I will pause the task in the meantime.
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Donnerstag, 25. Juli 2024 18:12
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
–
Jody Garnett
On Jul 25, 2024 at 3:42:13 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
–
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Welcome back Andreas,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
Here is my mad plan:
BTW: I will also be on holiday now until 2024-08-13.
I am speaking with my boss tomorrow, everyone has been away on vacation!
I made a post and GeoServer project steering committee has picked up one new silver sponsor ($3000/annual). I am still hoping for more interested parties (specificly for the github / google / geonode modules).
Jody Garnett
Hi Jody,
sorry, I missed your mail. The plan sounds reasonable to me.
Has it been clarified in the meantime who is to take over the migration or the creation of the new gs-sec-oidc module? And when should that be finished?
Should I have a look at it? Or can I help with something else? For example, there was still a task open that was about JS renovation, but I can’t find it right now.
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Dienstag, 20. August 2024 18:21
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Welcome back Andreas,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
Here is my mad plan:
BTW: I will also be on holiday now until 2024-08-13.
I am speaking with my boss tomorrow, everyone has been away on vacation!
I made a post and GeoServer project steering committee has picked up one new silver sponsor ($3000/annual). I am still hoping for more interested parties (specificly for the github / google / geonode modules).
Jody Garnett
On Aug 13, 2024 at 8:41:34 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I am back now. Please let me know when we can discuss how to continue with this. I will pause the task in the meantime.
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Donnerstag, 25. Juli 2024 18:12
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
–
Jody Garnett
On Jul 25, 2024 at 3:42:13 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
–
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Thanks Andreas,
I have been, and remain, very focused on the release crunch - and the wicket 9 update. Indeed there is a 2.26-M0 miledtone and a test plan taking shape:
https://github.com/geoserver/geoserver.github.io/pull/214
If you have capacity to start the gas-sec-oidc community module you are welcome to. I have do not have the capacity right now.
I was going to start by trying to take an inventory of what OAuth2 functionality is used. Most of my experience is with OIDC which has a number of optional settings now. I was hoping to start small and see what functionality needs to be added over time.
Jody Garnett
Hi Jody,
I’m just writing to confirm that I’ve started working on this task.
Did I understand correctly that, for now, the focus is on gs-sec-oidc providing “Login” with OpenID Connect rather than enabling GeoServer to act as a resource server in the OAuth2 sense?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Dienstag, 20. August 2024 18:21
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Welcome back Andreas,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
Here is my mad plan:
BTW: I will also be on holiday now until 2024-08-13.
I am speaking with my boss tomorrow, everyone has been away on vacation!
I made a post and GeoServer project steering committee has picked up one new silver sponsor ($3000/annual). I am still hoping for more interested parties (specificly for the github / google / geonode modules).
Jody Garnett
On Aug 13, 2024 at 8:41:34 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I am back now. Please let me know when we can discuss how to continue with this. I will pause the task in the meantime.
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Donnerstag, 25. Juli 2024 18:12
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
–
Jody Garnett
On Jul 25, 2024 at 3:42:13 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
–
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <Andreas.Watermeyer@…4886…>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
–
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
–
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, “Watermeyer, Andreas” <Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I do not believe that resource server use is supported by the existing security module.
I have personally used this to integrate with login with other credentials (keycloak or azure), so this is the only workflow I am sure of.
Jody Garnett
This part of the GS documentation sounds like this resource server use case (from https://docs.geoserver.org/latest/en/user/community/oauth2/oidc.html#openid-connect-with-attached-access-bearer-tokens):
*OpenID Connect With Attached Access Bearer Tokens*
The OpenID Connect plugin allows the use of Attached Bearer Access Tokens. This is typically used by automated (i.e. desktop or external Web Service) to access the Geoserver REST API.
Bearer Tokens
The setup process is as follows:
1. Setup your OAuth2 OpenID Connect configuration as normal
2. On the OpenID Connect configuration screen (bottom), makes sure “Allow Attached Bearer Tokens” is checked
3. You cannot use ID Tokens as a Role Source for the attached Bearer Tokens (see below)
To Use:
1. Obtain an Access Token from the underlying IDP
2. Attach the access token to your HTTP request headers
Authorization: Bearer <token>
The Access Token (JWT) is validated;
1. The Access Token is used to get the “userinfo” endpoint. The underlying IDP will verify the token (i.e. signature and expiry)
2. The Audience of the Token is checked that it contains the GeoServer configured Client Id. This make sure an Access Token for another application is not being inappropriately reused in GeoServer (cf. AudienceAccessTokenValidator.java).
3. The Subject of the userinfo and Access Token are verified to be about the same person. The OpenID specification recommends checking this (cf. SubjectTokenValidator.java).
Von: Jody Garnett <jody.garnett@...403...>
Gesendet: Dienstag, 17. September 2024 21:05
An: Watermeyer, Andreas <Andreas.Watermeyer@...4886...>
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
I do not believe that resource server use is supported by the existing security module.
I have personally used this to integrate with login with other credentials (keycloak or azure), so this is the only workflow I am sure of.
- -
Jody Garnett
On Sep 17, 2024 at 7:57:30 AM, "Watermeyer, Andreas" <mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I’m just writing to confirm that I’ve started working on this task.
Did I understand correctly that, for now, the focus is on gs-sec-oidc providing “Login” with OpenID Connect rather than enabling GeoServer to act as a resource server in the OAuth2 sense?
Best regards,
Andreas
Von: Jody Garnett <mailto:jody.garnett@…403…>
Gesendet: Dienstag, 20. August 2024 18:21
An: Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Welcome back Andreas,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
Here is my mad plan:
1. leave the existing gs-sec-oauth2-openid-connect community module in place - it can continue to operate for the 2.26 release cycle ... and be removed for 2.27.x when the spring-framework-6 update happens
2. make a copy as a new gs-sec-oidc module and adapt the spring-security-framework OAuth2 client ... to be developed during the 2.27 release cycle in September
3. folks can migrate to the new implementation while we use spring-security 5.8 and both are operational
4. when the spring-security 6.3 update happens gs-sec-oauth2-openid-connect is removed, and gs-sec-oidc remains available
5. once it meets the graduation requirements GeoCat would like to propose the new module as an extension. It may be a bit challenging (setting up some kind of online testing with GitHub workflow to achieve test coverage for example)
BTW: I will also be on holiday now until 2024-08-13.
I am speaking with my boss tomorrow, everyone has been away on vacation!
I made a https://geoserver.org/behind%20the%20scenes/2024/07/22/developer-update.html and GeoServer project steering committee has picked up one new silver sponsor ($3000/annual). I am still hoping for more interested parties (specificly for the github / google / geonode modules).
- -
Jody Garnett
On Aug 13, 2024 at 8:41:34 AM, "Watermeyer, Andreas" <mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I am back now. Please let me know when we can discuss how to continue with this. I will pause the task in the meantime.
Best regards,
Andreas
Von: Jody Garnett <mailto:jody.garnett@…403…>
Gesendet: Donnerstag, 25. Juli 2024 18:12
An: Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
--
Jody Garnett
On Jul 25, 2024 at 3:42:13 AM, "Watermeyer, Andreas" <mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <mailto:jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
--
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <mailto:jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
--
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <mailto:jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
--
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, "Watermeyer, Andreas" <mailto:Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
_______________________________________________
Geoserver-devel mailing list
mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Dear all,
that option in GeoServer OIDC allows the latter to validate the provided access tokens without the user intervention (no login challenge or redirection).
That said, by the meaning of “Resource Server” in the OAuth 2.0 and OpenID Connect frameworks, yes, it makes sense to define GeoServer acting as a Resource Server in this case.
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts!
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.
Hi Jody, hi all,
Here is a brief status update on the OAuth2 migration and a request for feedback:
- I decided to re-implement the existing functionality rather than trying to adapt the existing code. Reason: The Spring internals have changed too fundamentally. Additionally, the new Spring API allows for a much cleaner implementation, as far as I can tell at this point.
- I have completed a conceptual implementation. I am now working toward completeness (e.g., validation, PKCE, Web UI, etc.) and tidiness. Login works with Google (OpenID Connect), GitHub (OAuth2), and Spring Authorization Server (OpenID Connect).
- 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?
- The "Login" and "Resource Server" functionalities are split into two separate filters.
- In the Login Filter UI, it’s possible to activate a) Google and b) GitHub and c) one custom OpenID Connect provider (all three can be active). Due to Spring's internal structure, only one instance of this filter can be used. Therefore, it’s currently not possible to have two custom OpenID Connect providers — the Filter UI is currently too limited. Is this sufficient for now, or is it clear that this limitation won’t work?
- Multiple filters can be configured for the "Resource Server" use case.
- The new module was initially named "gs-sec-oidc". I suggest calling it "gs-sec-oauth2" instead, as it supports OAuth2 Login, OAuth2 Resource Server, and OpenID Connect Login (which is based on OAuth2).
- The Java package namespace of the existing modules is "org.geoserver.security.oauth2." Should we keep this? Pro: The name fits and renaming would require effort. Con: If users install both the previous and the migrated modules together — which certainly won’t work — the conflict may not be immediately apparent. My suggestion is to keep the package name.
Best regards,
Andreas
Von: Alessio Fabiani <alessio.fabiani@...6887...>
Gesendet: Donnerstag, 19. September 2024 00:07
An: Watermeyer, Andreas <Andreas.Watermeyer@...4886...>
Cc: Jody Garnett <jody.garnett@...403...>; geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Dear all,
that option in GeoServer OIDC allows the latter to validate the provided access tokens without the user intervention (no login challenge or redirection).
That said, by the meaning of "Resource Server" in the OAuth 2.0 and OpenID Connect frameworks, yes, it makes sense to define GeoServer acting as a Resource Server in this case.
On Wed, Sep 18, 2024 at 8:48 AM Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…> wrote:
This part of the GS documentation sounds like this resource server use case (from https://docs.geoserver.org/latest/en/user/community/oauth2/oidc.html#openid-connect-with-attached-access-bearer-tokens):
*OpenID Connect With Attached Access Bearer Tokens*
The OpenID Connect plugin allows the use of Attached Bearer Access Tokens. This is typically used by automated (i.e. desktop or external Web Service) to access the Geoserver REST API.
Bearer Tokens
The setup process is as follows:
1. Setup your OAuth2 OpenID Connect configuration as normal
2. On the OpenID Connect configuration screen (bottom), makes sure “Allow Attached Bearer Tokens” is checked
3. You cannot use ID Tokens as a Role Source for the attached Bearer Tokens (see below)
To Use:
1. Obtain an Access Token from the underlying IDP
2. Attach the access token to your HTTP request headers
Authorization: Bearer <token>
The Access Token (JWT) is validated;
1. The Access Token is used to get the “userinfo” endpoint. The underlying IDP will verify the token (i.e. signature and expiry)
2. The Audience of the Token is checked that it contains the GeoServer configured Client Id. This make sure an Access Token for another application is not being inappropriately reused in GeoServer (cf. AudienceAccessTokenValidator.java).
3. The Subject of the userinfo and Access Token are verified to be about the same person. The OpenID specification recommends checking this (cf. SubjectTokenValidator.java).
Von: Jody Garnett <mailto:jody.garnett@…403…>
Gesendet: Dienstag, 17. September 2024 21:05
An: Watermeyer, Andreas <mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
I do not believe that resource server use is supported by the existing security module.
I have personally used this to integrate with login with other credentials (keycloak or azure), so this is the only workflow I am sure of.
- -
Jody Garnett
On Sep 17, 2024 at 7:57:30 AM, "Watermeyer, Andreas" <mailto:mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I’m just writing to confirm that I’ve started working on this task.
Did I understand correctly that, for now, the focus is on gs-sec-oidc providing “Login” with OpenID Connect rather than enabling GeoServer to act as a resource server in the OAuth2 sense?
Best regards,
Andreas
Von: Jody Garnett <mailto:mailto:jody.garnett@…403…>
Gesendet: Dienstag, 20. August 2024 18:21
An: Watermeyer, Andreas <mailto:mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Welcome back Andreas,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
Here is my mad plan:
1. leave the existing gs-sec-oauth2-openid-connect community module in place - it can continue to operate for the 2.26 release cycle ... and be removed for 2.27.x when the spring-framework-6 update happens
2. make a copy as a new gs-sec-oidc module and adapt the spring-security-framework OAuth2 client ... to be developed during the 2.27 release cycle in September
3. folks can migrate to the new implementation while we use spring-security 5.8 and both are operational
4. when the spring-security 6.3 update happens gs-sec-oauth2-openid-connect is removed, and gs-sec-oidc remains available
5. once it meets the graduation requirements GeoCat would like to propose the new module as an extension. It may be a bit challenging (setting up some kind of online testing with GitHub workflow to achieve test coverage for example)
BTW: I will also be on holiday now until 2024-08-13.
I am speaking with my boss tomorrow, everyone has been away on vacation!
I made a https://geoserver.org/behind%20the%20scenes/2024/07/22/developer-update.html and GeoServer project steering committee has picked up one new silver sponsor ($3000/annual). I am still hoping for more interested parties (specificly for the github / google / geonode modules).
- -
Jody Garnett
On Aug 13, 2024 at 8:41:34 AM, "Watermeyer, Andreas" <mailto:mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
I am back now. Please let me know when we can discuss how to continue with this. I will pause the task in the meantime.
Best regards,
Andreas
Von: Jody Garnett <mailto:mailto:jody.garnett@…403…>
Gesendet: Donnerstag, 25. Juli 2024 18:12
An: Watermeyer, Andreas <mailto:mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Enjoy you vacation, I will be away for some weeks also. Lets catch up when we return (and hopefully some other parties will of stepped forward as interested by then).
--
Jody Garnett
On Jul 25, 2024 at 3:42:13 AM, "Watermeyer, Andreas" <mailto:mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
GeoCat is very much focused on OIDC and brining up such an extension to supported status.
What does that mean for the existing OIDC extension in the community section?
BTW: I will also be on holiday now until 2024-08-13.
Best regards,
Andreas Watermeyer
Von: Jody Garnett <mailto:mailto:jody.garnett@…403…>
Gesendet: Montag, 22. Juli 2024 18:52
An: Watermeyer, Andreas <mailto:mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Hi Andreas,
Thanks for replying I will update and publish the blog post.
GEOS-11271
That is great news that it is going smoothly.
GEOS-11272
GeoCat is very much focused on OIDC and brining up such an extension to supported status. The blog post is in part to see if anyone has capacity (or budget) to take on the generic OAauth2 functionality. Our developer who did the upgrade is on vacation presently, and may or may not be available to work on this when they return. Automated tests would be amazing - and test coverage is one of the tasks to hit to make this into a supported extension.
If you are in position to start on this activity please go ahead, or we can talk about approach now.
--
Jody Garnett
On Mon, Jul 22, 2024 at 1:44 AM Watermeyer, Andreas <mailto:mailto:Andreas.Watermeyer@…4886…> wrote:
Hi Jody,
regarding GEOS-11271- Upgrade spring-security to 5.8:
I started to work on this now. The upgrade itself seems to be limited to adjusting the pom only. I am now about to do some integration testing, also to become familiar with the GS functionality in that area.
Regarding GEOS-11272 spring-security-oauth replacement, with spring-security 5.8:
Considering GeoCat has done the same upgrade for the GeoNetwork codebase, GeoCat is probably in a much better position to work on this. Therefor I suggest that GeoCat takes over this task.
We could either provide further support on this task, for example in testing (manual or automated). I suppose automated integration tests are not yet existing. I suppose it would be possible to setup some integration tests with a dockerized OIDC server, for example Spring Authorization Server. Also, something else would be Ok to work on, for example “Refactor inline JavaScript in the OGC API modules” seems possible.
What do you think?
Best regards,
Andreas
Von: Jody Garnett <mailto:mailto:jody.garnett@…403…>
Gesendet: Freitag, 19. Juli 2024 08:01
An: Watermeyer, Andreas <mailto:mailto:Andreas.Watermeyer@…4886…>
Cc: mailto:mailto:geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Spring Security Upgrade
[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments.
Here is the blog post for review:
https://github.com/geoserver/geoserver.github.io/pull/205
I had a couple thoughts on how to approach the GEOS-11272 and have capacity to assist in this work.
--
Jody Garnett
On Thu, Jul 18, 2024 at 9:23 AM Jody Garnett <mailto:mailto:jody.garnett@…403…> wrote:
That would be great, and fit very well with our roadmap planning.
I am writing a blog post update about GEOS-11272 and other activities that are ready to be worked on.
Can I list you and your employer as a party working in this blog post?
--
Jody Garnett
On Jul 18, 2024 at 3:37:57 AM, "Watermeyer, Andreas" <mailto:mailto:Andreas.Watermeyer@…4886…> wrote:
Hi community,
I am now starting to work on:
GEOS-11271 : Upgrade spring-security to 5.8
GEOS-11272 : spring-security-oauth replacement, with spring-security 5.8
As far as I know no activities have taken place in this area so far. Otherwise please let me know.
Regards,
Andreas
_______________________________________________
Geoserver-devel mailing list
mailto:mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
_______________________________________________
Geoserver-devel mailing list
mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
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.
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
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@anonymised.com.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
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.bartoli@anonymised.com93…> 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)
ItalyW: http://www.geobeyond.it
M: +39 333 299 7173
S: francesco_bartoliT: 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