subject-c14n beans dependency on shibboleth.DataSealer

Scott Cantor scott at restingparrotsoftware.com
Wed Feb 25 16:30:12 UTC 2026


Looking at the wiring, it is not exactly expected in fact, I worked around it to make it work without the DataSealer. That doesn't mean it does work, but I'd have tested it in that specific case. I filed a bug, but I'll do the resting again and close it if I can't reproduce.

I would speculate that it's possible it's something to do with that replacement you have, but I don't exactly know what.

If you're trying to "replace" your bean under the same ID as we use, that won't work. It really never did, but you might have gotten away with it out of luck and Spring 7 is having a different opinion now.

This the bean's definition:

<bean id="c14n/SAML2CryptoTransient" class="net.shibboleth.idp.saml.nameid.impl.NameIDCanonicalization"
p:formats="#{ {'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'} }">

<property name="decoder">
<bean class="net.shibboleth.idp.saml.nameid.impl.CryptoTransientNameIDDecoder"
p:dataSealer="#{(environment.containsProperty('idp.sealer.storeResource') or environment.containsProperty('idp.sealer.keyStrategy')) ? getObject('shibboleth.DataSealer') : null}" />
</property>

</bean>


The idea is to do the conditional injection of the bean based on the same criteria already in place in the other wiring in the IdP.

-- Scott



More information about the dev mailing list