<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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).<br>
</p>
<p>Most of my attributes end up sourced from an LDAP data connector
"umnLDAP". <br>
</p>
We have an attribute in LDAP called umnCareerOffice that looks
something like this:<br>
<tt>umnCareerOffice: CCLC:DC,SPCCC</tt><br>
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).<br>
<br>
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:<br>
<tt>umnCareerOffice: Career and Community Learning Center,St. Paul
Career Counseling Center</tt><br>
<br>
To make this fly, we have the following attributes defined:<br>
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:<br>
<tt>umnCareerOfficeSplit: { "CCLC" , "SPCCC" }</tt><br>
<br>
umnCareerOfficeExpanded (dependency only, type Mapped, Dependency
ref="umnCareerOfficeSplit",
sourceAttributeID="umnCareerOfficeSplit"), which maps the
abbreviations to the spelled-out names, e.g.<br>
<tt>umnCareerOfficeExpanded: { "Career and Community Learning
Center", "St. Paul Career Counseling Center" }</tt><br>
<br>
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.<br>
<br>
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". <br>
<br>
I wouldn't be surprised if I'm Doing It Wrong. My understanding of
what Dependency actually means is sort of fuzzy.<br>
<pre class="moz-signature" cols="72">--
%% Christopher A. Bongaarts %% <a class="moz-txt-link-abbreviated" href="mailto:cab@umn.edu">cab@umn.edu</a> %%
%% OIT - Identity Management %% <a class="moz-txt-link-freetext" href="http://umn.edu/~cab">http://umn.edu/~cab</a> %%
%% University of Minnesota %% +1 (612) 625-1809 %%
</pre>
</body>
</html>