[EXT] idp 5.2.0 upgrade fails - org.opensaml.core.xml.config.XMLObjectProviderRegistry was unavailable

Paul B. Henson henson at cpp.edu
Thu Feb 12 02:32:47 UTC 2026


On Thu, Feb 12, 2026 at 02:05:06AM +0000, Paul B. Henson via users wrote:

> Is this a bug? Is there somewhere else other than global.xml I'm
> supposed to define this bean now? I don't recall why I defined it there,
> other than that's where all my random local custom beans are defined.

I tried moving the bean from global.xml to oidc-clientinfo-resolvers.xml;
it doesn't fail to start but it seems the bean isn't found in that
location:

2026-02-11 18:08:52,903 - / - WARN
[net.shibboleth.oidc.metadata.keyinfo.ext.impl.provider.ClientSecretReferenceProvider:98] - No values could be resolved for the client secret reference openidconnect.net

I tried putting it in services.xml but then it failed to process
relying-party.xml 8-/.

2026-02-11 18:17:59,567 - / - WARN [net.shibboleth.shared.spring.context.FilesystemGenericApplicationContext:628] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.UnverifiedRelyingParty' defined in file [/opt/shibboleth-idp/conf/relying-party.xml]: Cannot resolve reference to bean 'shibboleth.DefaultSecurityConfiguration' while setting bean property 'securityConfiguration'

I think I'll stop trying to stick it in random places for now <sigh>.

> That just isn't really a "configuration" sort of error, it's deep
> inside the system during startup. I'm not sure it's even possible to
> trigger it with a configuration change.                                                           
Seems you can :). Is there a prize for finding the most obscure bugs you
didn't think were possible ;)?

-- 
Paul B. Henson | Operating Systems and Network Analyst
henson at cpp.edu | California State Polytechnic University Pomona


More information about the users mailing list