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

[Cantor, Scott]

> I'm asking what the preferred way of adding/referencing an activation
> condition would be.

I don't have any preferred ways, just a personal feeling that beans should be scoped as low in the stack as possible and that if the desire is for reloadability then you don't have any real choice in the matter.

> Per the examples in services.xml, beans are defined and then referenced
> within services.xml. Based on those examples, it seems logical to put the
> following in services.xml:

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.

> <bean id="MyCondition" parent="shibboleth.Conditions.RelyingPartyId"
> c:candidate="https://sp.example.com/shibboleth" />
> 
> <util:list id="shibboleth.RelyingPartyResolverResources">
> <ref bean="MyCondition"/>
> <value>%{idp.home}/conf/relying-party.xml</value>
> <value>%{idp.home}/conf/credentials.xml</value>
> <value>%{idp.home}/system/conf/relying-party-system.xml</value>
> </util:list>

That list bean is a list of Spring Resources and that condition bean is not a Resource. Thus, it won't work (startup of that service should fail). Defining it by itself in any of the "root" Spring context's XML files, of which services.xml is one (and global.xml is another) would make the condition bean visible to any of the Spring contexts spun up for the various services, but would make the bean impossible to change/reload with those services. The advantage is it would be shareable across many different other places in the system, which is why global.xml is good for DataSource beans or things of that sort.

> Is it preferable instead to create a new xml file (relying-party-custom-
> beans.xml), and add that as another <value> line within
> shibboleth.RelyingPartyResolverResources as you've suggested?

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.

> At any rate, I do have the desired functionality after making the above
> changes to services.xml, with a couple caveats.
> 1) I get an error [error] when trying to reference the bean in
> shibboleth.RelyingPartyResolverResources. I needed to reference it in
> shibboleth.LegacyRelyingPartyResolverResources.

Neither is correct, and the second is just accidentally working because that legacy resources list bean isn't getting used anywhere. It's not working because you put it in the list, but because the bean just exists period.

> 2) In order for the attributes to be resolved/release properly, I had to define
> the attribute with the activation condition first in attribute-resolver.xml.
> [Definitions]

Spring loads all the beans in a context into pretty much one pile. Unless IDs overlap, there's no ordering issue possible. Also, you don't need separate AttributeDefinitions, that's the point of adding a condition on an encoder. It just goes in the same AttributeDefinition with the others.

If you were creating a separate attribute, there'd be no need for a condition at all, you'd just have separate release rules for the two attributes.

All you have to do is stick a second (or third) AttributeEncoder into the existing AttributeDefinition with the condition attached. If it's *also* necessary to prevent the original encoding from appearing for that SP, then you'd have to have two conditions in the mix, one to negate the other. At that point, I think I'd just create a second attribute.

-- Scott