IdP credentials for delegation Assertion signature validation

[Rod Widdowson]

Not understanding the delicacies of what you need to do, but from a configuration point of view

> But turns out that we don't actually load that context in the root Spring
> context or in any context visible to a flow.  It's just used as a config resource
> for the RelyingPartyConfigurationResolver service, which I guess has its own
> context.

This means that it is a reloadable file so you need to bear that in mind - you need to go through a service to get the info and I'd be inclined to leverage the one we have

Can you get what you need from net.shibboleth.idp.profile.config.SecurityConfiguration?  If so then you just need to plumb in shibboleth.RelyingPartyResolverService call getDefaultSecurityConfiguration on it and you are done.

Otherwise my suggestion would be either to add a method to do what you need to RelyingPartyConfigurationResolver and use shibboleth.RelyingPartyResolverService  as per above.

If this doesn't feels like a "RelyingParty" thing you can create a new interface to do what you need, make DefaultRelyingPartyConfigurationResolver implement it and then build your own service based around that.  I have currently swapped the precise details out on how to do this, but it's how the AttributeResolverImpl masquerades as an Attribute Resolver and an Attribute Mapper.

Or you could get completely radical and build your own Serviceable class which consumes (some of) the same beans as the RPConfig and from that build a service which takes the same input files as shibboleth.RelyingPartyResolverService and does exactly what you want.  You could add some lazy-init to our configs if you thought that the duplication would cost memory, but I don't see that happening.

I hope that answers your need, and isn't answering the wrong question.

Rod