SP: de-duping resolver plugin

[Martin Haase]

Hi Scott,

>> 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.
Ok... So the options are deduplication "before" alias processing and
"after"?

>> 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.
If possible I'd like to be application-independent. As the duplication
is "created" in the SP (by using multiple resolver plugins) and not in
the app, I think the duplication should be reverted there as well and
not in the app. Otherwise I'd need to instruct each app developer I will
give my consensus SP config to that they have to de-duplicate whatever
they get from the SP. The cases you draw up hold of course: only if the
app supports multiple values it could have a chance in de-duplicating.
But the point is that architecturally it should not be handled by the app.

> 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.
I'd base it on the SAML Attribute Name and the serialized value(s).

> (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.
ACK. How about putting the de-duplicator in the filtering stage?

> 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.
What comes to my mind, could I make Attribute Extraction on a
per-relying party basis, would that be possible? The docs do not suggest
that.
And, I guess I have another workaround: Just NOT accept any attributes
from Campus IdPs but the ePPN or whatever links the identities to the
central IdP. Only use the central IdP's attributes. As you wrote in the
linked post from May 4, 2011, REMOTE_USER does de-duping, so that would
be fine...

Cheers,
Martin

>
> -- Scott
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

-- 
-----------------------------------------------------------------------
Dr. Martin Haase
DAASI International GmbH                   phone:     +49 7071 407109-6
Europaplatz 3                              Fax  :     +49 7071 407109-9
D-72072 Tübingen                           email: Martin.Haase at DAASI.de
Germany                                    Web  :   http://www.daasi.de

Directory Applications for Advanced Security and Information Management
-----------------------------------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2332 bytes
Desc: S/MIME Kryptografische Unterschrift
Url : http://shibboleth.net/pipermail/dev/attachments/20120618/48b5f31e/attachment.bin