subject-c14n beans dependency on shibboleth.DataSealer

[Bachl, Mathias]

Hi!

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.
We use a custom Implementation instead (backed by a replicated in-memory cache instead of cryptography), and use it only for the OIDC plugin (configured with the "idp.oidc.tokenSealer" property).

We managed to work around the issue by setting "idp.sealer.storeResource" to a dummy value to make c14n/SAML2CryptoTransient use the default shibboleth.DataSealer with lockedAtStartup=true without any meaningful key configuration, but we don't use that c14n beans anyway.

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

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

Thanks in advance & best regards,
Mathias Bachl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20260225/60b857a5/attachment-0001.htm>