Circular dependency in attribute resolver

[Christopher Bongaarts]

On 5/11/2016 4:02 PM, Cantor, Scott wrote:
>> 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.
> What temporary objects?

I believe it's specific to Script attributes, to provide the V2 
emulation objects:

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
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
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
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}]
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}]
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}]
[...etc...]

At least it presumably goes away if I update the Script attributes to 
use the V3 interface.

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.

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

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.

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.

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.

-- 
%%  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/a37875e3/attachment-0001.html>