Attribute resolver dependency question/issue

[Tom Poage-3]

Greetings,

Ran across an issue where an attribute (eduPersonScopedAffiliation) is
released on some authentications (first log line below) and not others
(second line). IdP 2.3.3. Log lines from same server.

> 06:36:48.187 - INFO [Shibboleth-Audit:970] - 20120502T133648Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_7e52370bd1ae8de4417fbd797f989447|https://XXX.edu/|urn:mace:shibboleth:2.0:profiles:saml2:sso|urn:mace:incommon:ucdavis.edu|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_885fefeb71e10800b71b2d201f4e5a81|loginid|urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified|eduPersonPrincipalName,transientId,surname,eduPersonScopedAffiliation,givenName,email,displayName,|DE22T...||
> 06:38:35.263 - INFO [Shibboleth-Audit:970] - 20120502T133835Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_7ab58a59dbde89e01c811b7bb41ba47f|https://XXX.edu/|urn:mace:shibboleth:2.0:profiles:saml2:sso|urn:mace:incommon:ucdavis.edu|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_873e17b5ab439c0bcd23bffbe9cb76f1|loginid|urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|OTN2TTF...||

Our eduPersonAffiliation is stored in LDAP, but not scoped affiliation;
ePSA relies on ePA.

I had assumed specifying sourceAttributeID creates an implicit
dependency to the source attribute, so the dependency in ePSA on the
directory is not strictly required.

Question: should ePSA <resolver:Dependency> (specifics below) list the
dependent attribute identifier rather than the LDAP connector?

Can't seem to recreate with aacli.sh

Thanks!
Tom.

attribute-resolver.xml ePSA:

>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu" sourceAttributeID="eduPersonAffiliation">
>         <resolver:Dependency ref="ucdLDAP" />
>         <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>

... and add "member" value to ePA (if it contains any other value):

>     <resolver:AttributeDefinition id="eduPersonAffiliation" xsi:type="ad:Script" sourceAttributeID="eduPersonAffiliation">
>         <resolver:Dependency ref="ucdLDAP" />
>         <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
>         <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" />
>         <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>

And then filter out non-standard (internal legacy) values:

>     <!-- Filter out non-standard attribute values -->
>     <afp:AttributeFilterPolicy id="noRelease">
>         <afp:PolicyRequirementRule xsi:type="basic:ANY" />
>         <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="[hidden email]" ignoreCase="true" />
>         </afp:AttributeRule>
>         <afp:AttributeRule attributeID="eduPersonAffiliation">
>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="external" ignoreCase="true" />
>         </afp:AttributeRule>
>     </afp:AttributeFilterPolicy>

--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

Oops: RHEL 6 x86_64, Tomcat 6.0.24, httpd 2.2.15 w/ mod_proxy_ajp, JVM
1.6.0_31.

On 05/02/2012 11:24 AM, Tom Poage wrote:
> Greetings,
>
> Ran across an issue where an attribute (eduPersonScopedAffiliation) is
> released on some authentications (first log line below) and not others
> (second line). IdP 2.3.3. Log lines from same server.
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

Missed this page (and answered my own question).

https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverPluginDependency

Tom.

On 05/02/2012 11:29 AM, Tom Poage wrote:

> Oops: RHEL 6 x86_64, Tomcat 6.0.24, httpd 2.2.15 w/ mod_proxy_ajp, JVM
> 1.6.0_31.
>
> On 05/02/2012 11:24 AM, Tom Poage wrote:
>> Greetings,
>>
>> Ran across an issue where an attribute (eduPersonScopedAffiliation) is
>> released on some authentications (first log line below) and not others
>> (second line). IdP 2.3.3. Log lines from same server.
> --
> To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

You must specify both.  The source attribute ID indicates which
attribute out of the potentially many a given set of dependencies
might return.  Dependencies say which resolver plugins you want
providing that data.

There is a current limitation in the v2 resolver (addressed in v3)
that the source attribute ID must be the same across all dependencies.

On Wed, May 2, 2012 at 2:24 PM, Tom Poage <[hidden email]> wrote:

> Greetings,
>
> Ran across an issue where an attribute (eduPersonScopedAffiliation) is
> released on some authentications (first log line below) and not others
> (second line). IdP 2.3.3. Log lines from same server.
>
>> 06:36:48.187 - INFO [Shibboleth-Audit:970] - 20120502T133648Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_7e52370bd1ae8de4417fbd797f989447|https://XXX.edu/|urn:mace:shibboleth:2.0:profiles:saml2:sso|urn:mace:incommon:ucdavis.edu|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_885fefeb71e10800b71b2d201f4e5a81|loginid|urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified|eduPersonPrincipalName,transientId,surname,eduPersonScopedAffiliation,givenName,email,displayName,|DE22T...||
>> 06:38:35.263 - INFO [Shibboleth-Audit:970] - 20120502T133835Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_7ab58a59dbde89e01c811b7bb41ba47f|https://XXX.edu/|urn:mace:shibboleth:2.0:profiles:saml2:sso|urn:mace:incommon:ucdavis.edu|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_873e17b5ab439c0bcd23bffbe9cb76f1|loginid|urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified|eduPersonPrincipalName,transientId,surname,givenName,email,displayName,|OTN2TTF...||
>
> Our eduPersonAffiliation is stored in LDAP, but not scoped affiliation;
> ePSA relies on ePA.
>
> I had assumed specifying sourceAttributeID creates an implicit
> dependency to the source attribute, so the dependency in ePSA on the
> directory is not strictly required.
>
> Question: should ePSA <resolver:Dependency> (specifics below) list the
> dependent attribute identifier rather than the LDAP connector?
>
> Can't seem to recreate with aacli.sh
>
> Thanks!
> Tom.
>
> attribute-resolver.xml ePSA:
>
>>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu" sourceAttributeID="eduPersonAffiliation">
>>         <resolver:Dependency ref="ucdLDAP" />
>>         <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>
>
> ... and add "member" value to ePA (if it contains any other value):
>
>>     <resolver:AttributeDefinition id="eduPersonAffiliation" xsi:type="ad:Script" sourceAttributeID="eduPersonAffiliation">
>>         <resolver:Dependency ref="ucdLDAP" />
>>         <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
>>         <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" />
>>         <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>
>
> And then filter out non-standard (internal legacy) values:
>
>>     <!-- Filter out non-standard attribute values -->
>>     <afp:AttributeFilterPolicy id="noRelease">
>>         <afp:PolicyRequirementRule xsi:type="basic:ANY" />
>>         <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
>>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="[hidden email]" ignoreCase="true" />
>>         </afp:AttributeRule>
>>         <afp:AttributeRule attributeID="eduPersonAffiliation">
>>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="external" ignoreCase="true" />
>>         </afp:AttributeRule>
>>     </afp:AttributeFilterPolicy>
> --
> To unsubscribe from this list send an email to [hidden email]

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/02/2012 12:36 PM, Chad La Joie wrote:
> You must specify both.  The source attribute ID indicates which
> attribute out of the potentially many a given set of dependencies
> might return.  Dependencies say which resolver plugins you want
> providing that data.
>
> There is a current limitation in the v2 resolver (addressed in v3)
> that the source attribute ID must be the same across all dependencies.

Thanks. Good to know. So, more like this, then:

>>>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu" sourceAttributeID="eduPersonAffiliation">
>>>         <resolver:Dependency ref="ucdLDAP" />
>>>         <resolver:Dependency ref="eduPersonAffiliation" />
>>>         <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>

Tom.
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

I'd have to check the code but the main way I expect it to be used is
something like this

<Dependency plugin="foo" soureceAttribute="bar"/>

On Wed, May 2, 2012 at 3:48 PM, Tom Poage <[hidden email]> wrote:
> Thanks. Good to know. So, more like this, then:
>
>>>>     <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="ucdavis.edu" sourceAttributeID="eduPersonAffiliation">
>>>>         <resolver:Dependency ref="ucdLDAP" />
>>>>         <resolver:Dependency ref="eduPersonAffiliation" />
>>>>         <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>

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/02/2012 12:53 PM, Chad La Joie wrote:
> I'd have to check the code but the main way I expect it to be used is
> something like this
>
> <Dependency plugin="foo" soureceAttribute="bar"/>
>

OK, I was looking at this:

https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverPluginDependency

> <resolver:AttributeDefinition xsi:type="someType">
>     <resolver:Dependency id="myLDAP" />
>     <resolver:Dependency id="someAttributeDefinition" />
> </resolver:AttributeDefinition>

Hmm, which suggests to me ref="..." for an attribute is not correct.

Tom.
--
To unsubscribe from this list send an email to [hidden email]

[Cantor, Scott E.]

On 5/2/12 3:58 PM, "Tom Poage" <[hidden email]> wrote:

>On 05/02/2012 12:53 PM, Chad La Joie wrote:
>> I'd have to check the code but the main way I expect it to be used is
>> something like this
>>
>> <Dependency plugin="foo" soureceAttribute="bar"/>
>>
>
>OK, I was looking at this:
>
>https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverPluginDepende
>ncy

He was talking about the V3 change.

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.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/02/2012 01:00 PM, Cantor, Scott wrote:
> On 5/2/12 3:58 PM, "Tom Poage" <[hidden email]> 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.
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

On Thu, May 3, 2012 at 1:52 PM, Tom Poage <[hidden email]> wrote:
> The definitions are defined in the above order. Is definition order
> important in terms of triggering desired behavior?

No.  The order of plugin resolution is determined by the declaration
of one plugin depending on another.

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

I don't know, what you have right now will result in the following process:
- LDAP data connector will run
- The scripted attribute definition will run, create a new attribute
called "eduPersonAffiliation" and give it a value of "member"
- The Scoped attribute definition will run and pull in the values for
the "eduPersonAffiliation" (exact match on that name) LDAP attribute
and the "eduPersonAffiliation" attribute from the scripted data
connector and append the ucdavis.edu scope to all of them.

> 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).

That was a typo and has now been fixed.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/03/2012 11:15 AM, Chad La Joie wrote:
> On Thu, May 3, 2012 at 1:52 PM, Tom Poage <[hidden email]> wrote:
>> The definitions are defined in the above order. Is definition order
>> important in terms of triggering desired behavior?
>
> No.  The order of plugin resolution is determined by the declaration
> of one plugin depending on another.

Good. Faith in my understanding of this is restored. :-)

>> Is this simply a case of ambiguity, where the LDAP attribute name is the
>> same as the attribute id?
>
> I don't know, what you have right now will result in the following process:
> - LDAP data connector will run
> - The scripted attribute definition will run, create a new attribute
> called "eduPersonAffiliation" and give it a value of "member"

OK. I was under the impression that if the attribute existed (i.e. had a
value in LDAP), the script would operate on that list of values, the
'new' only being there if nothing was pulled from the directory (to
avoid an exception calling getValues() on a NULL).

> - The Scoped attribute definition will run and pull in the values for
> the "eduPersonAffiliation" (exact match on that name) LDAP attribute
> and the "eduPersonAffiliation" attribute from the scripted data
> connector and append the ucdavis.edu scope to all of them.

Ah, I didn't see them as separate containers that happened to have the
same identifier. Basically I wanted to add "member" if any value existed
in the LDAP attribute and remove the internal/legacy value "external",
leaving other values ("staff", "faculty", "student") intact. More or less:

>   if (eduPersonAffiliation.getValues().isEmpty() == false) {
>       eduPersonAffiliation.getValues().add("member");
>       if (eduPersonAffiliation.getValues().contains("external")) {
>           eduPersonAffiliation.getValues().remove("external");
>       }
>   }

(though the removal was actually being done in attribute-filter.xml).

>> 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).
>
> That was a typo and has now been fixed.

Thank you!
Tom.
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

On Thu, May 3, 2012 at 2:37 PM, Tom Poage <[hidden email]> wrote:
> OK. I was under the impression that if the attribute existed (i.e. had a
> value in LDAP), the script would operate on that list of values, the
> 'new' only being there if nothing was pulled from the directory (to
> avoid an exception calling getValues() on a NULL).

No, the result of one plugin is "scoped" to that plugin.  So the data
structure returned by the LDAP data connector has an attribute called
"eduPersonAffiliation" and the data structure returned by the
attribute definition also has one with that name.  You then decide
when to merge them together.  In this case you did so by declaring
both plugins as a dependency of the Scoped attribute definition.  That
definition creates, within its returned data structure, an attribute
called eduPersonAffiliation that contains the values from the
dependencies.

By having everything "scoped" to the plugin that produces the data you
can create some fairly sophisticated data processing pipelines in the
resolver.  One that merge and branch and multiplex data.  Most people
just want merging behavior which is why all the fixed logic plugins
(i.e., not the script ones) that we ship have that behavior.

> Ah, I didn't see them as separate containers that happened to have the
> same identifier. Basically I wanted to add "member" if any value existed
> in the LDAP attribute and remove the internal/legacy value "external",
> leaving other values ("staff", "faculty", "student") intact. More or less:

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


--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Christopher Bongaarts]

On 5/3/2012 1:59 PM, Chad La Joie wrote:

> By having everything "scoped" to the plugin that produces the data you
> can create some fairly sophisticated data processing pipelines in the
> resolver.  One that merge and branch and multiplex data.  Most people
> just want merging behavior which is why all the fixed logic plugins
> (i.e., not the script ones) that we ship have that behavior.

Any interesting use cases that come to mind for that?  Seems like it
might be a handy capability to use for some situations.
--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  [phone]    %%
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

Come to mind for what?

On Fri, May 4, 2012 at 10:56 AM, Christopher Bongaarts <[hidden email]> wrote:

> On 5/3/2012 1:59 PM, Chad La Joie wrote:
>
>> By having everything "scoped" to the plugin that produces the data you
>> can create some fairly sophisticated data processing pipelines in the
>> resolver.  One that merge and branch and multiplex data.  Most people
>> just want merging behavior which is why all the fixed logic plugins
>> (i.e., not the script ones) that we ship have that behavior.
>
> Any interesting use cases that come to mind for that?  Seems like it
> might be a handy capability to use for some situations.
> --
> %%  Christopher A. Bongaarts   %%  [hidden email]          %%
> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
> %%  University of Minnesota    %%  [phone]    %%
> --
> To unsubscribe from this list send an email to [hidden email]

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Christopher Bongaarts]

The more complicated branch/merge/multiplex cases for attributes.

On 5/4/2012 11:16 AM, Chad La Joie wrote:

> Come to mind for what?
>
> On Fri, May 4, 2012 at 10:56 AM, Christopher Bongaarts<[hidden email]>  wrote:
>> On 5/3/2012 1:59 PM, Chad La Joie wrote:
>>
>>> By having everything "scoped" to the plugin that produces the data you
>>> can create some fairly sophisticated data processing pipelines in the
>>> resolver.  One that merge and branch and multiplex data.  Most people
>>> just want merging behavior which is why all the fixed logic plugins
>>> (i.e., not the script ones) that we ship have that behavior.
>>
>> Any interesting use cases that come to mind for that?  Seems like it
>> might be a handy capability to use for some situations.
>> --
>> %%  Christopher A. Bongaarts   %%  [hidden email]          %%
>> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
>> %%  University of Minnesota    %%  [phone]    %%
>> --
>> To unsubscribe from this list send an email to [hidden email]
>
>
>

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  [phone]    %%
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

Usually it's something like:
- reading data from LDAP and one or more databases that share
overlapping attributes in different formats
- running the data from each data connector through different
template/scripts/maps in order to get them in to a common format
- merging those values together in to an attribute to be released
- potentially taking that new attribute and creating a scoped one to be released

Often this is done for affiliation or entitlements.

On Fri, May 4, 2012 at 12:42 PM, Christopher Bongaarts <[hidden email]> wrote:

> The more complicated branch/merge/multiplex cases for attributes.
>
> On 5/4/2012 11:16 AM, Chad La Joie wrote:
>> Come to mind for what?
>>
>> On Fri, May 4, 2012 at 10:56 AM, Christopher Bongaarts<[hidden email]>  wrote:
>>> On 5/3/2012 1:59 PM, Chad La Joie wrote:
>>>
>>>> By having everything "scoped" to the plugin that produces the data you
>>>> can create some fairly sophisticated data processing pipelines in the
>>>> resolver.  One that merge and branch and multiplex data.  Most people
>>>> just want merging behavior which is why all the fixed logic plugins
>>>> (i.e., not the script ones) that we ship have that behavior.
>>>
>>> Any interesting use cases that come to mind for that?  Seems like it
>>> might be a handy capability to use for some situations.
>>> --
>>> %%  Christopher A. Bongaarts   %%  [hidden email]          %%
>>> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
>>> %%  University of Minnesota    %%  [phone]    %%
>>> --
>>> To unsubscribe from this list send an email to [hidden email]
>>
>>
>>
>
>
> --
> %%  Christopher A. Bongaarts   %%  [hidden email]          %%
> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
> %%  University of Minnesota    %%  [phone]    %%
> --
> To unsubscribe from this list send an email to [hidden email]

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/04/2012 09:51 AM, Chad La Joie wrote:
> Usually it's something like:
> - reading data from LDAP and one or more databases that share
> overlapping attributes in different formats
> - running the data from each data connector through different
> template/scripts/maps in order to get them in to a common format
> - merging those values together in to an attribute to be released
> - potentially taking that new attribute and creating a scoped one to be released
>
> Often this is done for affiliation or entitlements.

and previously ...

>> Ah, I didn't see them as separate containers that happened to have the
>> same identifier. Basically I wanted to add "member" if any value existed
>> in the LDAP attribute and remove the internal/legacy value "external",
>> leaving other values ("staff", "faculty", "student") intact. More or less:

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

So I 'fixed' what I thought the issue was wrt an ordering dependency,
i.e. the suggestion to make the dependency explicit, but to no
avail--the composition of ePSA is inconsistent, sometimes it's
composed/released, sometimes not.

> 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...||

My reason for augmenting ePA prior to creating ePSA is related to
agility. I can add a new value to a list relatively quickly in the IdP,
not so quickly in the backing directory. This also applies to
creating/synthesizing assurance values based on combinations of other
attribute values, etc. I was also hoping to make whatever was in the
directory 'essential'--keep core values such as 'staff' and/or 'student'
for a client avoiding for the time being, if possible, populating
'member' for everybody. For us, 'member' currently only applies to SAML
and nothing else, so one perspective is: why 'litter' the directory with
marginally-useful stuff?

What is the recommendation for synthesizing/augmenting data coming in
from a connector? I was not so worried that it worked or didn't work,
but found myself disconcerted at the apparent non-determinism.

The LDAP dc:ResultCache TTL is 10 minutes. The above suggests that when
a record is fetched, ePSA is 'computed' and when data is pulled from
cache, it's not. Possible issue?

Thanks.
Tom.
--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

Debug trace. Why would eduPersonAffiliation not be cached?

Does the attribute filter operate on the cached LDAP data, so if I
filter it out in attribute-filter.xml, it's gone 'forever'?

Thanks.
Tom.

> 10:21:34.954 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:308] - Search filter: (uid=poage)
> 10:21:34.956 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:344] - LDAP data connector ucdLDAP - Checking cache for search results
> 10:21:34.958 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:351] - LDAP data connector ucdLDAP - No results cached for search filter '(uid=poage)'
> 10:21:34.958 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:363] - LDAP data connector ucdLDAP - Retrieving attributes from LDAP
> 10:21:35.129 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:414] - LDAP data connector ucdLDAP - Found the following attribute: eduPersonAffiliation[external]
...
> 10:22:16.179 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:344] - LDAP data connector ucdLDAP - Checking cache for search results
> 10:22:16.180 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:347] - LDAP data connector ucdLDAP - Returning attributes from cache
> 10:22:16.182 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:314] - Resolving attribute eduPersonAffiliation for principal poage
> 10:22:16.188 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:336] - Resolved attribute eduPersonAffiliation containing 0 values

>     <!-- Filter out non-standard attribute values -->
>     <afp:AttributeFilterPolicy id="noRelease">
>         <afp:PolicyRequirementRule xsi:type="basic:ANY" />
>         <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="[hidden email]" ignoreCase="true" />
>         </afp:AttributeRule>
>         <afp:AttributeRule attributeID="eduPersonAffiliation">
>             <afp:DenyValueRule xsi:type="basic:AttributeValueString" value="external" ignoreCase="true" />
>         </afp:AttributeRule>
>     </afp:AttributeFilterPolicy>

--
To unsubscribe from this list send an email to [hidden email]

[Cantor, Scott E.]

On 5/7/12 1:47 PM, "Tom Poage" <[hidden email]> wrote:

>Debug trace. Why would eduPersonAffiliation not be cached?

The only caching is the data connectors. The result set of the resolver on
the whole is not cached.

>Does the attribute filter operate on the cached LDAP data, so if I
>filter it out in attribute-filter.xml, it's gone 'forever'?

No. It's manipulating the released attributes, not acting on the data
connector results. Since the attribute defs are not cached in any sense,
the filter can't influence anything that's cached.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]

[Tom Poage-3]

On 05/07/2012 11:01 AM, Cantor, Scott wrote:

> On 5/7/12 1:47 PM, "Tom Poage" <[hidden email]> wrote:
>
>> Debug trace. Why would eduPersonAffiliation not be cached?
>
> The only caching is the data connectors. The result set of the resolver on
> the whole is not cached.
>
>> Does the attribute filter operate on the cached LDAP data, so if I
>> filter it out in attribute-filter.xml, it's gone 'forever'?
>
> No. It's manipulating the released attributes, not acting on the data
> connector results. Since the attribute defs are not cached in any sense,
> the filter can't influence anything that's cached.

OK, that's what I thought.

Still can't explain why on first authN a single ePA value is pulled from
the LDAP directory, and on second authN *zero* ePA values are in the
LDAP cache, even though all other attributes seem to be cached properly.

I would think the Script AttributeDefinition of ePA that relies on the
directory ePA value wouldn't affect what's maintained in the LDAP cache.
Hmm, maybe I should just turn off the LDAP cache altogether.

> <resolver:AttributeDefinition id="eduPersonAffiliation" xsi:type="ad:Script" sourceAttributeID="eduPersonAffiliation">
>    <resolver:Dependency ref="ucdLDAP" />
...

Tom.
--
To unsubscribe from this list send an email to [hidden email]