Activation condition by Relying Party on NameID generators for IdPv3

[Michael A Grady]

> On Oct 19, 2015, at 1:17 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
> 
> 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.
> 

Thanks. 
Switching the 2nd one to:  <bean parent="shibboleth.Conditions.RelyingPartyId" c:_0="#{{'relyingpartyz'}}" />
did indeed get them working; the first (c:candidates="#{ {'relyingpartyX', 'relyingpartyY'} }" ) did indeed work without changes.

--
Michael A. Grady
IAM Architect, Unicon, Inc.