SP: de-duping resolver plugin

[Cantor, Scott]

On 6/19/12 9:47 AM, "Martin Haase" <martin.haase at daasi.de> wrote:

>understood, although I only taught and never really used the alias
>feature.

I don't use it either. I don't necessarily object to building a feature
that ignores it or creates problems only when it's used, but I have to
take it into account.

>>Ok, but when would the application developer need to do this, but
>> otherwise be fine handling multiple values?

>I suspect with multiple emails? If the app is dumb it would enter all
>available values into its database, including duplicates...

In practice email as an attribute tends to be single valued because people
use it as an identifier so often, but ok.

>> I looked there because that's really where the work should be, but it
>> really doesn't work right now. The filtering stage doesn't get access to
>> all of the attributes that have been previously resolved by different
>> plugins. Changing that is more than I'm prepared to tackle in a minor
>> update.
>Maybe for another non-minor update?

Yes, but that isn't imminent. It's a large effort to do a 3.0 because you
only get so many chances to break APIs, so you have to plan for it.

>Yeah, and preferably on a per-attribute base, because e.g. for mail or
>givenName one might want to allow for multiple values, but for eppn not.

Yes, I meant per-attribute ID, not globally.

>What about the following (also likely non-minor):
>Define some rules in the filtering stage that say something like: "If
>IdP X provided attribute A, take A from X and filter out all other
>occurences of A. If IdP X didn't provide A, take A from IdP Y etc...".
>This could have additional value besides just de-duplicating.

Yes, it has the same problem, right now the filtering step happens inside
plugins that obtain attributes from external sources, and the filtering
only accesses the attributes being resolved, not anything resolved earlier.

I suspect that a re-design would address the preservation of source
information throughout the life cycle, and then support a built-in
filtering operation at the very end that ran against everything.

-- Scott