idpv3 attribute-resolver + PluginActivationConditions

[Tom Scavo]

On Thu, Aug 27, 2015 at 7:46 AM, Jarno Huuskonen <jarno.huuskonen at uef.fi> wrote:
>
> Is possible to use ExternalAttributePluginActivationConditions
> (shibboleth.Conditions.RelyingPartyId)
> (https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAttributePluginActivationConditions)
> with "RelyingPartyByGroup" ?
>
> For example if I have edugain metadata with:
> <md:EntitiesDescriptor ... Name="http://edugain.org/" ...>
> is it possible to match this group Name with
> shibboleth.Conditions.RelyingPartyId in attribute-resolver ?
>
> And is it possible to negate ActivationConditions ?
> (to have a condition where edugain-group gets this attribute-resolver
> and !edugain-group(everybody else) gets something else).

I can't answer your technical questions directly but I will try to
steer you away from leveraging the EntitiesDescriptor/@Name XML
attribute in the first place. First, you need to come up with a better
example since IdPs are not supposed to be updating eduGAIN metadata
directly. Even if you can produce a more realistic use case, IdP
operators are advised not to leverage the EntitiesDescriptor/@Name XML
attribute since 1) the composition of aggregates is subject to change,
so today's policy (based on Name) is tomorrow's headache, and 2)
per-entity metadata distribution is in our not-too-distant future, so
IdP configurations should focus on entity characteristics, not the
aggregate.

The intended use case for EntitiesDescriptor/@Name involves nested
EntitiesDescriptor elements, but I don't think that feature of SAML
metadata is being used today, and moreover, I don't think it ever will
be used.

Tom