<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 5/11/2016 4:02 PM, Cantor, Scott wrote:<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128F6EB8@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
What temporary objects?</pre>
</blockquote>
<br>
I believe it's specific to Script attributes, to provide the V2
emulation objects:<br>
<br>
<tt>2016-05-11 16:07:31,009 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:210]
- Attribute Definition 'umnCareerOfficeSplit': adding
to-be-populated attribute to script context</tt><tt><br>
</tt><tt>2016-05-11 16:07:31,009 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:216]
- Attribute Definition 'umnCareerOfficeSplit': adding contexts to
script context</tt><tt><br>
</tt><tt>2016-05-11 16:07:31,009 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:226]
- Attribute Definition 'umnCareerOfficeSplit': adding emulated V2
request context to script context</tt><tt><br>
</tt><tt>2016-05-11 16:07:31,009 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:231]
- Attribute Definition 'umnCareerOfficeSplit': adding dependent
attribute 'umnOTRSuppress' with the following values to the script
context: [StringAttributeValue{value=TRUE}]</tt><tt><br>
</tt><tt>2016-05-11 16:07:31,010 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:231]
- Attribute Definition 'umnCareerOfficeSplit': adding dependent
attribute 'umnRemoteAccess' with the following values to the
script context: [StringAttributeValue{value=FALSE}]</tt><tt><br>
</tt><tt>2016-05-11 16:07:31,010 - DEBUG
[net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition:231]
- Attribute Definition 'umnCareerOfficeSplit': adding dependent
attribute 'umnSuppress' with the following values to the script
context: [StringAttributeValue{value=entry}]</tt><tt><br>
</tt><tt>[...etc...]</tt><tt><br>
</tt><br>
At least it presumably goes away if I update the Script attributes
to use the V3 interface.<br>
<br>
BTW, I tried the change above (Dependency on umnLDAP) and it
worked. It just makes the IdP do extra work in copying all those
attributes.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128F6EB8@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">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".
</pre>
</blockquote>
<pre wrap="">
No, but you can rename LDAP attribute results now also.
I would be interested to know if V3 would allow you to define a dependency on a specific DataConnector attribute though. I hope not, and that this represents a change that prevents something V2 didn't mean to allow but did.
</pre>
</blockquote>
<br>
I went through my resolver conf and verified that every attribute
referenced in a Dependency had a corresponding attribute definition
(typically a Simple depending on umnLDAP). So I don't have any
direct dependencies on any DC attributes.<br>
<br>
But now at least I've got another workaround: I can define a Simple
attribute with some other name (e.g. "umnCareerOffice-LDAP-Edition",
sourced from the LDAP umnCareerOffice (via a Dependency on umnLDAP
and appropriate sourceAttributeID), and use that as the Dependency
for umnCareerOfficeSplit. Or I could use the LDAP field renaming.<br>
<br>
Fortunately, it's not very common for us to want a Shib attribute
with the same name as an LDAP attribute to be released with a
completely different value.<br>
<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>