skipping duplicate Attribute mapping (same name and nameFormat)

[Cantor, Scott]

>Here is the appropriate excerpt from my attribute-map.xml
>
>-----
><!-- Second, an alternate decoder that will decode the incorrect form
>     into the newer form.
>-->
><Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
>           id="persistent-id">
>  <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
>      formatter="$NameQualifier!$SPNameQualifier!$Name"
>      defaultQualifiers="true"/>
></Attribute>

That one you need to disable because you've left the earlier one enabled.
Hopefully it's ignored, but that's relying on unspecified behavior. That's
why it's commented out by default, because the earlier one is enabled. I
don't think it should be hurting anything, but you don't want to depend on
that.

The others are what I'd expect.

>AIUI, the "First" declaration (for targeted-id) causes the "Second" (for
>persistent-id) to be ignored in all cases.
>
>Is that correct?

Maybe. Duplication of rules is unsupported. If the code changed in some
way and started taking the last one that it saw, that would be within the
documented behavior. It's unspecified how duplicate rules are handled.

>My theory is that the XML contains strange values but I can't confirm
>that with the logs I have.

Given what you posted, there probably have to be values that are
questionable, if not wrong. There shouldn't be any scoped values in any of
the data mapped to "persistent-id", because that would mean the scoped
values are actually inside a NameID element. That's not exactly illegal in
that the values of a persistent NameID are just opaque, but it suggests
configurations that are very odd and certainly not a good idea.

>What would I need to change in the rules above?

Just commenting out the duplicate rule for safety sake, but the rest of
what you're seeing is just bad data and people sending nonsense, or the
same data in multiple ways. They're all IdP mistakes.

>Rather than drop support entirely (because we do speak to some non SAML
>2.0 IDPs) I'd rather decode those NameIDs to different webserver
>variables.

You can't decode the same thing on the wire to different variables based
on the IdP. Not without application overrides, per IdP resources, and
per-application extraction rules. There is no support in the extractor for
rules based on IdPs.

Based on your rules, any cases where there are values in "persistent-id"
that don't match each other is a mistake on the part of the IdP that I
couldn't explain without seeing what they're sending and their
configurations, and then it would just be a matter of pointing out what
they screwed up. There's no way to fix it once it's been sent. And if they
have apps depending on bad data, there is no way out but to fix things in
some deliberate way.

-- Scott