Attribute resolver dependency question/issue

[Tom Poage]

On 05/07/2012 12:03 PM, Cantor, Scott wrote:
> On 5/7/12 2:20 PM, "Tom Poage" <tfpoage at ucdavis.edu> wrote:
>>
>> Commenting out the LDAP connector cache directive makes the ePA (and
>> ePSA) behavior consistent and deterministic.
>>
>> So, not sure now whether it's my attribute definitions or something
>> about how the LDAP connector cache behaves that I don't understand.
> 
> If you have log entries showing the *connector* returning two different
> results, then I'd say that's a bug.

I refactored the attribute definition, pulling apart the source
attribute and the script definition, and re-enabled the LDAP cache.

>     <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonAffiliation" sourceAttributeID="eduPersonAffiliation" dependencyOnly="true">
>         <resolver:Dependency ref="ucdLDAP" />
>     </resolver:AttributeDefinition>
...
>     <resolver:AttributeDefinition id="ucdEPA" xsi:type="ad:Script" dependencyOnly="true">
>         <resolver:Dependency ref="eduPersonAffiliation" />
>         <ad:Script><![CDATA[
>              importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
>              ucdEPA = eduPersonAffiliation.clone();
>              if (ucdEPA.getValues().isEmpty() == false) {
>                  if (!ucdEPA.getValues().contains("member")) {
>                       ucdEPA.getValues().add("member");
>                  }
>              }
>         ]]></ad:Script>
>     </resolver:AttributeDefinition>
...
>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu">
>         <resolver:Dependency ref="ucdEPA" />
>         <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" />
>         <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" friendlyName="eduPersonScopedAffiliation" />
>     </resolver:AttributeDefinition>

eduPersonScopedAffiliation now looks to be generated and released
consistently, whether directly fetched from the directory or retrieved
from the LDAP cache.

So, renaming what I thought was *the* eduPersonAffiliation attribute
definition, and what I now understand is a completely separate/distinct
attribute container--even if it happened to have the same name--somehow
"unmasked" the cached LDAP affiliation attribute.

Behavior is also the same if I swap the ucdEPA and eduPersonAffiliation
identifiers, i.e.

>     <resolver:AttributeDefinition xsi:type="ad:Simple" id="ucdEPA" sourceAttributeID="eduPersonAffiliation" dependencyOnly="true">
...
>     <resolver:AttributeDefinition id="eduPersonAffiliation" xsi:type="ad:Script" dependencyOnly="true">
>         <resolver:Dependency ref="ucdEPA" />
>         <ad:Script><![CDATA[
>              importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
>              eduPersonAffiliation = ucdEPA.clone();
...
>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu">
>         <resolver:Dependency ref="eduPersonAffiliation" />

I don't know if this falls under the "not recommended" Chad mentioned.

> Right, you can do that but that's not what your code did, it's more
> complicated, and I wouldn't recommended it.

Tom.