Shibboleth.DEPRECATION : MetadataGenerator handler
peter.schober at univie.ac.at
Mon Dec 6 15:56:28 UTC 2021
* Cantor, Scott <cantor.2 at osu.edu> [2021-12-06 15:20]:
> It also may be kind of moot, since Java generally supports
> everything we could possibly support (we even support ECDH
> encryption now).
Thanks, good point. Of course I'd still need to know who's running the
the new SP vs. the old one then (unless there'll be some way to
determine that, e.g. different default endpoint structures).
> It should scale better than it does now, but TLS is TBD. That means
> key management and a lot of extra work and technical debt that we're
> hoping to avoid. I would expect something like stunnel would be more
OK, so the Apache module (as the one initiating connections to shibd)
would handle the TLS client-side and stunnel would provide the TLS
server, itself connecting to a non-TLS TCP socket listening on the
> The issue isn't so much the deployment
Allow me to remain mildly sceptical.
(And happy to be wrong, of course.)
> but the configuration. The Java part is going to have to be
> configured largely the way the IdP is. I don't expect that to appeal
> to most people.
Heh. Point taken about the configuration, although there's a wide
compexity spectrum available on the IDP side, from very simple (Java
properties files) to the custom config of an attribute resolver/filter
to Spring beans.
More information about the users