skipping duplicate Attribute mapping (same name and nameFormat)

[Cantor, Scott]

>
>Therefore I need a way to select a specific attribute per IDP as ending
>up with a multi-valued persistent-id with non equivalent values, in an
>arbitrary and undefined order is not useful.

Well, one step forward, I suppose, is to make sure you never map anything
in the broken form into the alias "persisent-id". That should at least
isolate the cases to some degree. You're in a scenario where moving to
"correct" state is impossible, so you definitely need to turn off the
features that are meant to assist with migrating to "correct" state.

>In the "sends single values targeted-id and tri-valued persistent-id,
>last persistent-id matches targeted-id, first and second persistent-
>ids match each other but don't match targeted-id" case in my original
>mail, I see
>
>targeted-id = "X at scope"
>persistent-id = "SP!IDP!Y;SP!IDP!Y;SP!IDPX at scope"

But you shouldn't be seeing a scoped value in that last value, the
NameIDFromScoped decoder should be stripping it. You shouldn't have
anything mapping a scoped value of any kind into that alias. Nothing I
provide does that.

>I also see things like
>
>targeted-id = "Z at scope"
>persistent-id = "SP!IDP!Z;SP!IDP!Z at scope"

Same thing, I don't see how that's possible. The token $Name in the
formatter in the rule is eplicitly only the left hand side of the scoped
expression.

>and
>
>targeted-id = "W at scope"
>persistent-id = "SP!IDP!W;SP!IDP!W"

And I don't see any way that's possible given the above. I think you need
to actually tell me what mapping rules you're using here. And it's
possible the underlying XML being sent is also wrong in some unforeseen
way that's causing problems with the code. Again, eliminating the
NameIDFromScoped case should clean up some of this.

>...so I have a need to distinguish the values sent inside attributes
>with different URIs and a need to choose a particular URI on a per IDP
>basis.

It's not a feature currently. Other than by explicitly handling all the
XML of course.

>We are trying to be "liberal in what we accept" and we have very little
>influence over what we are sent due to operational issues on the IDP side.
>
>We're in an inter-federated environment so it's only going to become
>more important to be able to deal with these issues on the SP side.

You can make some small improvements by eliminating options like SAML 1.1
support, requiring a persistent NameID, that kind of thing. But that
mostly just eliminates duplication that likely is not hurting anything
other than looking ugly. What you can't do is map attributes differently
based on the IdP, not without creating per-IdP resource URLs. The mapping
layer by itself cannot do it.

-- Scott