Change the "name=" value for the UID attribute definition for specific entityIDs

[Joseph Fischetti]

> That is not logical, but since I don't know how you're arriving at that conclusion, I can't speak to exactly why you might think that.

The example I'm referring to in services.xml.

<bean id="TheSVNResource" class="net.shibboleth.ext.spring.resource.SVNResource">
<constructor-arg ref="ClientMgr" />
<constructor-arg ref="TheSVNURL" />
<constructor-arg value="D:/testdir/dir" />
<constructor-arg value="-1" />
<constructor-arg value="TestResource.txt" />
</bean>

<util:list id="shibboleth.AttributeResolverResources">
<ref bean="TheSVNResource"/>
<value>path_to_properties_specifyingBean_file</value>
</util:list>


That does seem to define a bean, and then reference said bean in the util:list. But maybe that's a more specific use case and/or I'm reading it wrong. The entire example is line 9 through 49 and is commented as "Advanced configuration of services from SVN"



>It is correct. Whether it's preferable depends on what you have to do with the bean you're defining. 
> I have both cases in my own IdP but if I can define it inside a service's resources and not globally, that's what I do.

I believe I now have it working as you describe, based on our back and forth:
- I created conf/resolver-custom-beans.xml
- I specified the new bean with id="CAS5-SP", parent, and candidate.
- I added <value>%{idp.home}/conf/resolver-custom-beans.xml</value> to <util:list id ="shibboleth.AttributeResolverResources">
- I condensed my attribute definition into a single attribute and included a separate encoder with activationConditionRef="CAS5-SP"
- Now the non-specified SP receives only the default attribute, while the specified SP receives both.


Joseph Fischetti 
Linux System Administrator 
Marist College