subject-c14n beans dependency on shibboleth.DataSealer

[Scott Cantor]

>  After upgrading from IdP 5.1.x to 5.2.1 we had the following issue:
>  Beans like “c14n/SAML2CryptoTransient“ (see subject-c14n-system.xml) failed to initialize because we do not had the default shibboleth.DataSealer implementation configured.

I'm not surprised, I was expecting something like that. You can file a bug, but I don't know that it's easily fixable.

>  Is this change in behavior intended? Couldn’t that c14n beans be made lazy-loaded?

No, it can't. Many of them were, they can't be anymore because of the change to the design. The breakage isn't intentional, but it has never been fully supported to not have the DataSealer spin up, it was simply "best effort" and it's quite messy.

>  Using a custom DataSealer implementation still seems not to be straightforward in the IdP core – are there any plans to change that (e.g. allow the used bean to be configured with a property like it is possible with the OIDC plugin)?

We need to make it an interface a la the StorageService. We should do that for V6.

-- Scott