[GIP] Replace Security Proxy by new Gateway component

[emmdurin]

[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 :

• Authentification OAuth2 et OpenID
• Authentification par headers HTTP ajoutés par un autre composant de confiance
• Support de HTTP/2 et Websockets

[EN] What ?

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

• OAuth2 and OpenID authentication
• Authentication by HTTP headers set by another trusted component
• HTTP/2 and Websockets support

[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 ?

• Migration de la configuration du Security Proxy au format Gateway chez les utilisateurs, il y a déjà un paragraphe explicatif dans le ReadMe de la Gateway, ainsi qu'une documentation plus complète dans le répertoire adocs, possiblement à compléter
• Evaluer le risque de cas isolés non envisagés de bug ou de fonctionnalité manquante

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

• Migration of Security Proxy configuration to Gateway format at user's end, there is already a explanatory paragraph in Gateway ReadMe and a more precise documentation in adocs directory, maybe to complete
• Estimate the risk of isolated cases of bug or missing feature

[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]

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]

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]

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:

[landryb]

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:

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]

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]

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

• has this been tested outside of docker/k8s ?
• will it be supported by c2c outside of docker/k8s ?
• will there be proper documentation on how to run it outside of docker/k8s ?
• will there be debian packages to integrate properly like other georchestra components ?
• since its a critical infrastructure component, will all related documentation be updated (eg apache config ? or it's time to drop it..)
• https://github.com/georchestra/georchestra-gateway/tree/main/datadir is only required to run tests, at runtime it uses the regular datadir in /etc/georchestra/gateway ?
• will there be proper documentation/examples on how to migrate an existing instance in the migration notes for 24 ?

[fvanderbiest]

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]

• 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]

• 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.

• https://github.com/georchestra/georchestra-gateway/tree/main/datadir is only required to run tests, at runtime it uses the regular datadir in /etc/georchestra/gateway ?

Yes.

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

Yes.

[fvanderbiest]

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]

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

No.
Backward compatibility is maintained.

[landryb]

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]

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]

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]

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

[landryb]

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:

• you know what spring boot is
• you're fluent with its configuration gotchas

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]

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:

• https://github.com/georchestra/datadir/blob/master/gateway/application.yaml#L1-L7
• https://github.com/georchestra/datadir/blob/master/gateway/gateway.yaml#L1-L4

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

[pmauduit]

+1 for me

+1 for me as well

[landryb]

fwiw, this GIP is still open, and in light of georchestra/georchestra-gateway@8beee0d 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.