SP: de-duping resolver plugin

[Cantor, Scott]

On 6/18/12 4:45 AM, "Martin Haase" <martin.haase at daasi.de> wrote:

>(taking this to dev from
>https://issues.shibboleth.net/jira/browse/SSPCPP-466 a per Scott's
>suggestion.)

Thanks.

>I'm preparing a sample SP configuration for several applications I do
>not know beforehand. They use the SimpleAggregationAttributeResolver to
>query attributes from a central IdP. If both a campus IdP and the
>central one did not provide some set of necessary attributes, the user
>is redirected to a registry SP where they fill in the missing
>attributes, into the same LDAP the central IdP takes them from.

Ok.

>There are two alternatives: Either the campus IdP didn't provide them,
>then they come only from the central IdP, hence no duplicates. Or, if
>the campus IdP provided them, they eventually come from both IdPs and
>need to be merged.

Right now, they end up as totally discrete attributes that may be mapped
to any number of local names (because of the alias feature). Some of the
local names may map to values that are duplicated, others may not. Even at
the same time. So the semantics of "deduplication" are very unclear.

Now, I'm not fond of the alias feature, I actually tried to leave it out
of 2.0, and I'm increasingly interested in deprecating it and dropping it
in a future 3.0 release. I think it limits what assumptions can be made so
that these kinds of use cases can be dealt with. But for right now, it's
there, so it has to be factored in.

>Thus it is not about multi-valued attributes in general, which is up to
>the application to honor or not. E.g. if the campus IdP asserts
>givenNames John and Joe, these two get registered in the central LDAP,
>and will be released from the central IdP as well, leading to
>"John;Joe;John;Joe". I could imagine two ways to handle that: a) merging
>duplicates if they come from multiple attribute resolvers, or b)
>irrespective of the source, optionally let only unique values pass to
>the application. (I'd prefer a)...)

But I still haven't seen the underlying problem that needs to be solved.
How can it not be about multi-valued attributes? If you support multiple
values, then the duplicates can't really matter to you. If you can't
handle multiple values, then any additional values, duplicate or not, will
cause a problem.

So I don't understand how this isn't really about limiting value count
rather than duplicates. What is the actual problem that the duplicate
value causes?

Fundamentally, I don't see how to implement (a). What is a duplicate? What
if the attribute ID matches but the set of aliases is different? What if
the serialized form happens to match but the underlying attribute type is
different? Etc.

(b) at least can be implemented in terms of the application variables
being created. It's not efficient, but it's at least unambiguous to say
that any header/variable exported is de-duplicated. That can't be done in
a plugin, but it's possible to do it in the export step.

Also, attributes don't currently maintain a "source" indicator. So there's
no way to know that one attribute came from a different source as another
once it's been filtered and added to the resolved set. I would think the
source (meaning the issuer) matters more than the particular resolver
plugin that happened to generate the attribute.

But if the plugin were treated as the relevant issue, then it's possible
to do *something*, but it would require identifying a very precise
definition of "duplicate" that probably won't address any but a very
specific use case.

-- Scott