Attribute resolver dependency question/issue

[Tom Poage]

On 05/02/2012 01:00 PM, Cantor, Scott wrote:
> On 5/2/12 3:58 PM, "Tom Poage" <tfpoage at ucdavis.edu> wrote:
>> https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverPluginDependency
> 
> I think your issue was that you had an ordering dependency that you didn't
> make explicit. If the affiliation attribute has scripty bits that have to
> run, and then you want scoped affiliation to get built, you have to make
> the script a dependency, or it can choose to resolve LDAP alone and then
> scoped affiliation, and leave out the affiliation.

So I made ePSA explicitly depend on ePA, with (as I understood Chad to
say) both attribute and data connector as dependencies.

>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu" sourceAttributeID="eduPersonAffiliation">
>         <resolver:Dependency ref="eduPersonAffiliation" />
>         <resolver:Dependency ref="ucdLDAP" />
...
>     </resolver:AttributeDefinition>

>    <resolver:AttributeDefinition id="eduPersonAffiliation" xsi:type="ad:Script" sourceAttributeID="eduPersonAffiliation">
>         <resolver:Dependency ref="ucdLDAP" />
...
>         <ad:Script><![CDATA[
>              importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
>              if (eduPersonAffiliation == null) {
>                  eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation");
>              }
>              if (eduPersonAffiliation.getValues().isEmpty() == false) {
>                  eduPersonAffiliation.getValues().add("member");
>              }
>         ]]></ad:Script>
>     </resolver:AttributeDefinition>

The "non-deterministic" issue remains where some authentications for
this particular user include ePSA and some don't.

Recall that an internal legacy value for ePA and ePSA is filtered out in
attribute-filter.xml, suggesting the script is not being triggered prior
to evaluating ePSA.

> 20120503T154947Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,eduPersonScopedAffiliation,givenName,email,displayName,|P7CQC...||
> 20120503T155020Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|I7YMF...||
> 20120503T155323Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|TF3KF...||
> 20120503T155416Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|V5I3Y...||
> 20120503T155556Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|PN4FO...||
> 20120503T160541Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,eduPersonScopedAffiliation,givenName,email,displayName,|JXRJG...||
> 20120503T160631Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|55CKI...||
> 20120503T161745Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,eduPersonScopedAffiliation,givenName,email,displayName,|GYTZG...||
> 20120503T161845Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|...|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|ZGCLQ...||

The definitions are defined in the above order. Is definition order
important in terms of triggering desired behavior?

Is this simply a case of ambiguity, where the LDAP attribute name is the
same as the attribute id?

Lastly, the wiki page above indicates id="..." instead of ref="..." for
resolver:Dependency. I don't see 'id' in the XSD (or perhaps I'm not
reading it correctly).

Thanks.
Tom.