Shibboleth Developers

[Chad La Joie <>]

The new code doesn't work any differently than the current code in this
respect.  Data connectors expose some number of attributes, which may
have overlapping attribute IDs.  Attribute definitions must then merge
the values and produce the final form of the attributes and there can
not be duplicate IDs at that level.  So, the application will never see
duplicate attributes.

Tom Scavo wrote:
> On 4/30/07, Scott Cantor 
> <>
>  wrote:
>>
>> ...we do not
>> expect to shib the Java SP with the 2.0 release due to time
>> constraints and
>> overall lateness, and the native SP is not going to have this particular
>> resolver plugin implemented initially. So I guess you could say that, no,
>> it's not a planned feature of the 2.0 SP.
> 
> Okay, I didn't know that, thanks.
> 
>> I do plan to eventually port the Java resolver over and make it work,
>> however, aside from what the eventual Java version will have, and I
>> have the
>> same goal as Chad, not to distinguish between local and remote data.
> 
> I'm working on this right now and from what I've been able to
> determine it seems like merging attributes from two sources is not as
> simple as it seems.  In your case, what if each source issues an
> attribute with the same name?  Since the issuers are distinct, it
> seems the attributes are distinct, but how will the application know
> which is which?
> 
>> However, attributes are ultimately objects that store whatever data one
>> wants, so if the resolver and attribute decoders wanted to extract and
>> store
>> information about the source and make that accessible to applications, I
>> don't see any reason why they couldn't do so.
> 
> Ah, okay.  I would think this would be required, however, otherwise
> the application sees two attributes with the same name and wouldn't
> know which is which.
> 
> Tom

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