10:55 a.m.
* Christian Franke <christian.franke(a)chronist.net> [2023-01-30 23:38]:
All in all our setup looks roughly like this:
+---------+ OIDC +--------+ SAML +---------+
| Web App |---------| Satosa |---------| IdPs |
+---------+ +--------+ +---------+
| MDQ
+--------+ HTTP +--------------------------+
| pyFF |---------|Federation Metadata Server|
+--------+ +--------------------------+
| MDQ
+-----------+
| thisss.js |
+-----------+
While this is all great (and no offence intended) let me just say that
I think it is complete madness to expect people to maintain this kind
of software stack only to enable them to connect one service "to
eduGAIN", i.e., to offer services to the academic community.
Just to provide some contrast: Personally I have used the Shibboleth
SP together with Apache httpd for many years with great success,
protecting many different kinds of applications and using different
kind of "application servers"[1]). This makes the setup essentially
look like this:
+---------+ SAML +--------+
| Web App |---------| IdPs |
+---------+ +--------+
But of course this does not have a mini-application-IDM system or
multi-protocol proxy such as Keycloak or Satosa in the mix. I also
realise people/projects have different needs and preferences and
deployment preferences change over the years.
Best,
-peter
[1] PHP-FPM + mod_proxy_fgci for PHP apps, uWSGI + mod_proxy_uwsgi for
Python and Perl (and Ruby), Tomcat + mod_proxy_ajp for Java.
For Node.js, golang, etc. based web servers resorting to HTTP/WS
Reverse Proxying from Apache httpd still works fine but I prefer
tunnelling with more "protocol fidelity" over HTTP/WS Reverse
Proxying whenever possible.