Shibboleth.DEPRECATION : MetadataGenerator handler

Cantor, Scott cantor.2 at osu.edu
Mon Dec 6 14:20:11 UTC 2021


On 12/6/21, 9:06 AM, "users on behalf of Peter Schober" <users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:

>    (Others will likely report the sharing the supported crypto algorithms
>    as a security "vulnerability". ;))

That's the problem, yes, but I don't see much point in including anything we can't default on.

It also may be kind of moot, since Java generally supports everything we could possibly support (we even support ECDH encryption now).

>    [1] Which is of course impossible to predict. Maybe the continued
>    pressure to Containerize All The Things will make a Java-based shibd
>    less of an issue, with deployers "just" loading an image with that
>    part of the SP and a matching JVM. It would of course help if
>    Java-shibd then sufficiently scaled to connect via TCP sockets,
>    possibly protected with [m]TLS?

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

The issue isn't so much the deployment, 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. But this is what we can do, and the alternative is "do nothing and sunset it" unless somebody shows up willing to commit to a decade of maintenance and to rewrite Xerces.

-- Scott




More information about the users mailing list