Circular dependency in attribute resolver

[Christopher Bongaarts]

I've bumped into a situation with the attribute resolver where I'm 
unsure of the best way to proceed.  This is in the context of 
IdPv3(.2.1), as part of upgrading from v2(.4.x).

Most of my attributes end up sourced from an LDAP data connector "umnLDAP".

We have an attribute in LDAP called umnCareerOffice that looks something 
like this:
umnCareerOffice: CCLC:DC,SPCCC
The value is basically a comma delimited list of the career offices from 
which a student/alum is entitled to receive services.  Some values may 
include a ":DC" suffix which indicates that a Degree has been Conferred 
(i.e. the user actually graduated).

We release this attribute to an SP that expects to see a comma delimited 
string attribute value with the office names spelled out and no suffix; 
e.g. for the value above:
umnCareerOffice: Career and Community Learning Center,St. Paul Career 
Counseling Center

To make this fly, we have the following attributes defined:
umnCareerOfficeSplit (dependency only, type Script, Dependency 
ref="umnCareerOffice"), which basically splits the LDAP attribute values 
at the commas and then adds each office (minus the suffix if present). 
For the above example:
umnCareerOfficeSplit: { "CCLC" , "SPCCC" }

umnCareerOfficeExpanded (dependency only, type Mapped, Dependency 
ref="umnCareerOfficeSplit", sourceAttributeID="umnCareerOfficeSplit"), 
which maps the abbreviations to the spelled-out names, e.g.
umnCareerOfficeExpanded: { "Career and Community Learning Center", "St. 
Paul Career Counseling Center" }

umnCareerOffice (type Script, Dependency ref="umnCareerOfficeExpanded", 
sourceAttributeID="umnCareerOfficeExpanded"), which generates the final 
value to be delivered to the SP (see above) by joining the values from 
Expanded with commas.

The IdP refuses to load this configuration, because of the circular 
dependency around umnCareerOffice.  I suspect I may be able to fix it by 
changing the umnCareerOfficeSplit Dependency to the data connector 
umnLDAP with umnCareerOffice as a sourceAttributeID.   But it would be 
nice to avoid having to generate temporary objects for all of the LDAP 
attributes in the entry just to get one of them.  Or maybe there's some 
other way to say "this attribute depends on the umnLDAP attribute 
umnCareerOffice, not the IdP attribute with the same name".

I wouldn't be surprised if I'm Doing It Wrong.  My understanding of what 
Dependency actually means is sort of fuzzy.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160511/688408fd/attachment.html>