Shibboleth Developers

[Chad La Joie <>]

I think this is already taken care of in 2.0.  We use Sets (SortedSets
to be exact) for value lists.  So, for simple "native" type values (int,
long, float, string, etc.) filtering will be automatically handled.  For
other types you'll just need to make sure the implement the
equals(Object) and hashCode() methods in a way that meets your
definition of equality.

Ian Young wrote:
> It's common in directory contexts to regard a multi-valued attribute as
> having a set of values: which is to say, the values are all different
> (no duplicates) and you don't care about their ordering.
> 
> I can't find any indication that SAML takes an explicit position on
> attribute values, but my observation is that the OpenSAML 1 code (and
> thus the 1.3.x IdP) implements everything using ArrayLists, which is to
> say that if you push three "foo" values in, then they'll all come out
> the other end and ultimately end up in the application at the SP as
> "foo;foo;foo".
> 
> This came up recently while I was setting an IdP up to merge entitlement
> values from multiple sources; although each source had no duplicates in
> its own set, it was possible for the same value to come in from two
> sources and thus end up with a duplicated value in the result.  I guess
> I'd have wanted it to be possible to omit the duplicated values without
> having to jump through hoops.
> 
> In terms of current hoops, things are made slightly trickier because the
> list of values isn't visible through the ResolverAttribute interface, so
> anything (like a scriptlet attribute definition) that wants to do
> duplicate removal can't ask if a value is a duplicate using something
> like a contains() method.  That means that it needs to build its own
> collection and finally -- because there is no addAll(Collection) method
> in ResolverAttribute -- push each of the resulting non-duplicate values
> through one at a time once the full collection has been built.
> 
> Now, I'm not saying this is a vital problem (an application would have
> to be pretty brittle to have trouble if it got the same entitlement
> value twice, in my view) and I'm certainly not suggesting that it is
> worth doing anything about this in 1.3.  However, it might be worth
> looking at in 2.0 to see whether one of the following might be easy to
> provide:
> 
> * some sort of contents examination in ResolverAttribute or its equivalent
> 
> * an addAll method
> 
> * a "filter out duplicate values" attribute plugin
> 
> * a general "filter out duplicate values" facility for attributes
> 
> Just a thought,
> 
>       -- Ian

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124