Circular dependency in attribute resolver

[Cantor, Scott]

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

I think that's one of those "oh, you can't be serious that it works" situations Rod would have to remind me about. There was never any intent that you could depend on a DataConnector attribute, only DataConnectors or AttributeDefinitions themselves. I think it only works accidentally and you really should not count on it.

The attributes produced by a data connector are unfortunately too "exposed" but they're meant to be private to a "context" represented by the data connector, and it's the data connector you should depend on.

> 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?

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

-- Scott