Shibboleth Developers

[Chad La Joie <>]

Honestly I don't remember exactly when it's done.  You'd have to look at 
the code.

If it's done at the end it was probably just in the name of efficiency. 
 If it's done after a plugin resolves then you have to scan the values 
N times.

On 1/5/11 7:42 AM, Halm Reusser wrote:
> Hi (Chad),
>
> My attribute resolving query for a RDBMS data connector produces a table
> like (for principal=user1):
>
> | uid | ... | entitlement |
> +-------+-----+---------------------+
> | user1 | ... | http:/example.org/1 |
> | user1 | ... | http:/example.org/2 |
>
>
> Because the user1 has of some attribute (e.g., entitlement) more than
> one values. It produces multiple data rows instead of one (which is the
> case for a user with only single valued attributes).
>
>  From this query result the IdP creates all the attributes as defined. If
> multiple rows are returned, multi valued attributes are created.
>
> Because the IdP is filtering out duplicate values, that should work fine.
>
> Now, there is another data connector, like:
>
> <resolver:DataConnector id="storedIdConnector" xsi:type="dc:StoredId"
> generatedAttributeID="persistentID"
> sourceAttributeID="uid"
>
> which cause this log entry:
>
> WARN
> [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.StoredIDDataConnector:241]
>
> - Source attribute uid for connector storedIdConnector has more than one
> value, only the first value is used
>
> So, my assumption is, that attribute filtering (removal of duplicates)
> is done after ALL attributes (using all dependent data connectors) are
> resolved. Is this right?
>
> If, yes, do you think it would be helpful to remove duplicates direct
> after resolving?
>
> Thanks!
> -Halm

--
Chad La Joie
http://itumi.biz
trusted identities, delivered