IdPv3 - Combining HTTP resources with local files for filter, relying party , etc.

[Cantor, Scott]

On 10/20/15, 9:54 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>When one configures in multiple filter files, or relying party files, etc., including ones brought in from HTTP, I assume each distinct file needs to be schema-compliant, correct?

Yes.

> So each filter file would need the containing :AttributeFilterPolicyGroup element. But what is the minimum necessary in a relying party resource? I.e if I just want to be able add some RelyingPartyOverrides from a remote source, would that relying party file just need:
>
> - the containing <beans ..> element
> - the containing <util:list id="shibboleth.RelyingPartyOverrides"> element
> - the  various overrides

No, it's not that simple. The shibboleth.RelyingPartyOverrides bean is what gets injected inside the system. You can include <ref> elements pointing to beans defined in other files loaded into the context, but there's still only one shibboleth.RelyingPartyOverrides bean. If you redefine that, you're just hiding the others.

You can play some games with list merging (advanced Spring feature), but one list bean would have to point to another list bean and so on, and the final merged list has to be a bean with that name.

>So can one leave out the UnverifiedRelyingParty,  DefaultRelyingParty, etc. config, just having that in one of the relying party resources?

Those can (and must) be left out of all but one file, yes.

>I assume if want wants to use any "tempate beans", those would also need to be defined within that same <beans> container?

No. A bean can inherit from a parent bean defined anywhere in the same or a parent/root Spring context.

-- Scott