georchestra / improvement-proposals

0 stars 0 forks source link

[GIP] Replace Security Proxy by new Gateway component #8

Open emmdurin opened 6 months ago

emmdurin commented 6 months ago

[FR] Qui ?

Camptocamp, avec les soutiens financiers de Deutsche Telekom, de la MEL et de l'INRAE

[EN] Who ?

Camptocamp, with financial support from Deutsche Telekom, MEL and INRAE

[FR] Elements concernés

Security Proxy, remplacé par un nouveau composant nommé Gateway

[EN] Target Module

Security Proxy, replaced by a new component named Gateway

[FR] Quoi ?

Remplacement du Security Proxy par une solution plus moderne basée sur Spring Cloud Gateway et Spring Webflux, apportant de nouvelles fonctionnalités :

[EN] What ?

Replacement of Security Proxy with a more modern solution based on Spring Cloud Gateway and Spring Webflux, with new features :

[FR] Pourquoi ?

Modernisation du point d'entrée vers les applications geOrchestra, besoin de nouvelles méthodes d'authentification, support de nouveaux protocoles

[EN] Why ?

Modernization of entry point to geOrchestra applications, need for new authentication methods, support for new protocols

[FR] Comment ?

Par remplacement du Security Proxy par le nouveau composant Gateway

[EN] How ?

By replacing Security Proxy with the new Gateway component

[FR] Identifiez-vous d'éventuels problèmes et avez-vous une idée sur la façon de les circonvenir ?

[EN] Any potential pitfalls and ways to circumvent them ?

[FR] Quand ?

Finalisation en cours, sortie pour geOrchestra 24.

L'idée est d'offrir une période d'un an aux utilisateurs pour migrer vers le nouveau composant, la release 24.0 supportant indifféremment Security Proxy et Gateway.

geOrchestra 23.0.x - Security Proxy geOrchestra 24.0.x - Security Proxy ou Gateway au choix geOrchestra 25.0.x - Gateway

[EN] When ?

Finalization in progress, targeting geOrchestra release 24

The plan is to offer a one year migration period to geOrchestra users, the 24.0 release supporting both the Security Proxy and the Gateway.

geOrchestra 23.0.x - Security Proxy geOrchestra 24.0.x - Security Proxy or Gateway geOrchestra 25.0.x - Gateway

State of the vote:

PSC members vote
Fabrice Phung +1
François Van Der Biest +1
Pierre Mauduit
Landry Breuil +1
Stéphane Mével-Viannay +1
Maël Reboux
Pierre Jégo +1
Jean Pommier +1
Catherine Piton-Morales +1
catmorales commented 6 months ago

Hello ! geOrchestra is expected by our DSN for this enhancement. However, I have some questions about this development.

Some answers can be found on https://github.com/georchestra/georchestra-gateway/blob/main/README.md, but I'd like more details.

Http headers

Will the proxyfied applications (using sec- http headers) need to be adapted? Will the sec- parameters change?

Logs

What about the OGC protocols? I understand they are not implemented in the gateway. So what can we do to have something similar to analyse our platform usage? Will it be synchronised with the analytics work in progress? https://github.com/georchestra/analytics/tree/main

SMTP

What about the SMTP function that exists with SP (we use it in a mapstore plugin but we can change our usage) ?

LOSSES

Are there any other security proxy functions that are likely to disappear?

fvanderbiest commented 6 months ago

About the OGC logs, we collectively decided it's a bad idea to have the gateway handle them. It should be another component's responsibility. The upcoming Code Sprint will help get a better idea of what's coming next.

Regarding the SMTP proxy feature, you probably mean the mailservice that is part of the console application, and allows users to send emails to other users as long as they have the EMAILPROXY role. Since it's part of the console, rather than the security-proxy, it should just work as previously. No expected impact (kudos to @pmauduit for reminding me that it's part of the console rather than the SP).

My colleagues will provide answers for the 2 other questions.

fvanderbiest commented 6 months ago

Are there any other security proxy functions that are likely to disappear?

Not implemented with the gateway for now: user last connexion date as seen in the console: image

landryb commented 6 months ago

Are there any other security proxy functions that are likely to disappear?

Not implemented with the gateway for now: user last connexion date as seen in the console: image

wait, what ? that's an ldap attribute server side, what would this have to do with the sec-proxy/gateway ? or the gateway doesn't bind the user to the ldap with its credentials as the s-p probably does now ?

fvanderbiest commented 6 months ago

Oh, my bad, it's because the user is managed by an Identity Provider ! Local users do have the information filled. Relieved ;-) Sorry for the noise.

landryb commented 6 months ago

I'll play the (obvious) devil's advocate:

fvanderbiest commented 6 months ago

Added a missing note in the GIP description "The plan is to offer a one year migration period to geOrchestra users, the 24.0 release supporting both the Security Proxy and the Gateway."

pmauduit commented 6 months ago
  • has this been tested outside of docker/k8s ?

This is something I was willing to explore during next week's codesprint (debian packaging, CICD on paulla infra, ansible playbook, ...)

fvanderbiest commented 6 months ago
  • has this been tested outside of docker/k8s ?

Not yet

  • will it be supported by c2c outside of docker/k8s ?

We have no use case with our current customers regarding this. You should get in touch to get a quote ;-)

  • will there be proper documentation on how to run it outside of docker/k8s ?

Depends on the above.

  • will there be debian packages to integrate properly like other georchestra components ?

Same.

  • since its a critical infrastructure component, will all related documentation be updated (eg apache config ? or it's time to drop it..)

Documentation will be provided with the component, but anything related with Apache is now obsolete and will be removed in the coming weeks.

Yes.

  • will there be proper documentation/examples on how to migrate an existing instance in the migration notes for 24 ?

Yes.

fvanderbiest commented 6 months ago

We have no use case with our current customers regarding this. You should get in touch to get a quote ;-)

Or we can just have a code sprint ;-)

fvanderbiest commented 6 months ago

Will the proxyfied applications (using sec- http headers) need to be adapted? Will the sec- parameters change?

No. Backward compatibility is maintained.

landryb commented 3 months ago

added my +1, though i consider the sample configuration to be an abomination calling for proper documentation/customization examples...

i guess we'll see what's actually missing when in production :)

fvanderbiest commented 3 months ago

added my +1, though i consider the sample configuration to be an abomination calling for proper documentation/customization examples...

Thanks Landry for the feedback. We'll try to fix this asap.

pmauduit commented 3 months ago

though i consider the sample configuration to be an abomination calling for proper documentation/customization examples...

Could you be more precise about this point (e.g. bad behaviours in the sample config, or so) ? There is a documentation in the sources tree here already: https://github.com/georchestra/georchestra-gateway/blob/main/docs/index.adoc

catmorales commented 3 months ago

+1 for me because we are expecting for OAuth2 et OpenID support .

landryb commented 3 months ago

though i consider the sample configuration to be an abomination calling for proper documentation/customization examples...

Could you be more precise about this point (e.g. bad behaviours in the sample config, or so) ? There is a documentation in the sources tree here already: https://github.com/georchestra/georchestra-gateway/blob/main/docs/index.adoc

and.. how am i supposed to get there when i'm reading yaml in the datadir ? :) bits of that docs seem to be meant for developers only btw...

what i mean by abomination (ok, maybe a strong word) is that i only see tons of yaml structures, some of them apparently redundant (eg from a high pov gateway/routes.yaml seem to define things twice), gateway/gateway.yaml has very few comments about the whys of which value for which parameter, and so on...

some of this assumes:

i know this config has been written over time when building/developing the gateway, and most of the config values are a direct mapping of the security proxy config but... just look at the comments in security-proxy/security-proxy.properties or security-proxy/proxy-permissions.xml - that's what i call "self-documenting config" :)

otherwise, it just feels we're trading XML & properties files (so 90's!) with comments/explanations that were carefully constructed over the years for a blob of yaml, because that's the new hotness (thanks to k8s)

if i'm a georchestra platform admin, and say i want to add a path to redirect to a new application, i look in the files, i curse, then i run away screaming ;)

but don't worry, i will be able to get over it.. i'm more concerned about other platform admins who don't closely follow the development.

pmauduit commented 3 months ago

how am i supposed to get there when i'm reading yaml in the datadir ?

There may indeed lack a bit of "migrating from geOrchestra's security-proxy" documentation (and a one explaining what is about configuring spring cloud gateway versus what is about georchestra custom config), but the yaml files from the datadir are already commented somehow:

so, yeah, there is still room for improvement for sure

pmauduit commented 3 months ago

+1 for me

+1 for me as well

landryb commented 1 month ago

fwiw, this GIP is still open, and in light of https://github.com/georchestra/georchestra-gateway/commit/8beee0dae592eb9a9db232e096ca00652bd391a9 i'd like to stress that since this commit, java 21 is a requirement to build the gateway (i have no idea for runtime).

If the gateway is a core component of georchestra, then that requirement should be properly written somewhere... this broke the community builds of the gateway, because that requirement wasnt discussed anywhere.