Activation condition by Relying Party on NameID generators for IdPv3

[Cantor, Scott]

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

>                 <property name="activationCondition">
>                        <bean parent="shibboleth.Conditions.RelyingPartyId"
>                         c:candidates="#{ {'relyingpartyX', 'relyingpartyY'} }" />
>                </property>

That looks ok to me.

>                <property name="activationCondition">
>                        <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="relyingpartyz" />
>                </property>

That's only going to work in 3.2, you should get an error locating a constructor or a matching parameter now.

>If I remove the above, everything works as expected. So at least one it doesn't like. Now I know I also saw the config for doing an OR with a list, although the 'candidates' versus 'candidate' seemed like it might take a list.

The candidates list is an OR (obviously, you can't be named A and B).

> So is it trying having multiple for 'candidates', or is it that a single candidate needs to still have the  #{ {'relyingpartyz'} } syntax, or ?

My examples use the c:_0 syntax and only document things that specifically work, and passing a single value in a string doesn't work, that's what the extra constructor was added to fix. My examples stick to passing lists, regardless of how many elements there are.

-- Scott