subject-c14n beans dependency on shibboleth.DataSealer

[Bachl, Mathias]

That sounds good, thank you very much!


-----Ursprüngliche Nachricht-----
Von: dev <dev-bounces at shibboleth.net> Im Auftrag von dev-request at shibboleth.net
Gesendet: Donnerstag, 26. Februar 2026 13:00
An: dev at shibboleth.net
Betreff: dev Digest, Vol 176, Issue 5

ACHTUNG: Diese E-Mail stammt von einem externen Absender (auch wenn diese Absenderadresse als intern angezeigt wird). Bitte vermeiden Sie es, Anhänge oder externe Links von unbekannten Absendern zu öffnen!


Send dev mailing list submissions to
        dev at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://shibboleth.net/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
        dev-request at shibboleth.net

You can reach the person managing the list at
        dev-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..."


Today's Topics:

   1. Re: subject-c14n beans dependency on shibboleth.DataSealer
      (Scott Cantor)
   2. Re: subject-c14n beans dependency on shibboleth.DataSealer
      (Scott Cantor)
   3. Re: subject-c14n beans dependency on shibboleth.DataSealer
      (Scott Cantor)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Feb 2026 10:52:19 -0500
From: Scott Cantor <scott at restingparrotsoftware.com>
To: Shib Dev <dev at shibboleth.net>
Subject: Re: subject-c14n beans dependency on shibboleth.DataSealer
Message-ID:
        <11594F20-627B-418D-98ED-C75B6EC3CCFD at restingparrotsoftware.com>
Content-Type: text/plain;       charset=utf-8


>  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



------------------------------

Message: 2
Date: Wed, 25 Feb 2026 11:30:12 -0500
From: Scott Cantor <scott at restingparrotsoftware.com>
To: Shib Dev <dev at shibboleth.net>
Subject: Re: subject-c14n beans dependency on shibboleth.DataSealer
Message-ID:
        <3C1DA699-5FE2-4ADC-8C39-E89C9A997589 at restingparrotsoftware.com>
Content-Type: text/plain;       charset=us-ascii

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



------------------------------

Message: 3
Date: Wed, 25 Feb 2026 11:41:13 -0500
From: Scott Cantor <scott at restingparrotsoftware.com>
To: Shib Dev <dev at shibboleth.net>
Subject: Re: subject-c14n beans dependency on shibboleth.DataSealer
Message-ID:
        <C1F1E806-1105-43B7-9DE2-21C123A647A1 at restingparrotsoftware.com>
Content-Type: text/plain;       charset=us-ascii

> 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'm wrong, I spotted the bug, and its easily fixable.

-- Scott



------------------------------

Subject: Digest Footer

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net


------------------------------

End of dev Digest, Vol 176, Issue 5
***********************************