Shibboleth IdP v3 multiple entityID config question

[Cantor, Scott]

On 5/18/15, 1:45 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
>
>In short we have two entityID's for our IdP. The V3 config has the entityID being set in the idp.properties. and It doesn't look like there is an easy way to allow it to understand a second.
> Is there a way to allow the IdP to understand it's has two entityID's assigned to it?

Same as before, it's a bean property on the RelyingPartyConfiguration objects. The new property is called responderId and it's set in system/conf/relying-party-system.xml to a bean called entityID which is set via the Java property, it's at the top of the file.

You can override it as required on your RelyingPartyConfiguration beans (no need to touch anything in the system file).


Java properties are *not* the way the system is configured, Spring is. If the properties are too limiting, you do it yourself. If you want to create a second Java property called idp.entityID2 and reference that in the XML because you love properties, you can do that. You do whatever you want/need, basically.

>In the old system it was easy to support both since we had to load the metadata anyway and then you just specified in the relying-party.xml which provider id to use. Nothing jumps out in the V3 config that seems to allow the same thing.

Exactly the same thing, but you have to look at the Javadoc for the classes being configured by Spring because there's no custom XML syntax to wrap it with different terminology. You're wiring the Java class directly. That's why the wiki docs link to Javadocs quite often.

In a nutshell, put p:responderId="myvalue" into any of the overrides you define, or define a property and indirect it through the property to avoid duplication, your choice. You could even define a parent bean with that override in it, and then inherit specific RelyingParty overrides from that parent bean to pull in the value.

-- Scott