Attribute resolver dependency question/issue

[Tom Poage]

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.