Shibboleth Developers

["Scott Cantor" <>]

> 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.

It's a little less clean right now in the SP, although I'm still working on
it. It seems difficult in practice to "merge" attributes after the fact or
by checking for an attribute with id="foo" when creating another attribute
with id="foo", especially since the values could in principal be different
syntaxes.

Perhaps partly because I have to string-ify everything for the application
anyway, I'm leaning toward a multimap internally (just a map where you can
have duplicate keys) and just requiring anything internal to the system to
deal with the fact that multiple Attribute objects can be in the cache with
the same id.

Ultimately, the deployer controls all this anyway, and giving things the
same "id" is asking for conflicts like this. But the value of it is that you
can handle the case where different IdPs assert different SAML attributes
but it all ends up normalized to one Attribute id. I just don't think I want
to merge them automatically if both show up.

> > 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?

As Chad said, what do you do in the IdP now? You would typically map it to a
distinct name internally if you cared about the distinction.

> > 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.

The intent is that the deployer has to guard against this and with all the
different connectors and mappers, you generally have to *intentionally* give
things the same name. Admittedly the typical IdP-oriented connectors like
JNDI and JDBC tend to just pump out data using the source repository's name,
but I might suggest that those connectors ought to have name-remapping
features anyway to simplify these cases.

Point being, I guess, that it's really not "intrinsic" to the work we're
doing on the overall component APIs, and is something individual connectors
and resolvers can certainly deal with.

-- Scott