skipping duplicate Attribute mapping (same name and nameFormat)

[Cantor, Scott]

On 9/4/14, 2:04 PM, "Andy Bennett" <andyjpb at knodium.com> wrote:

>I have an SP configured such that all of the targeted-id and
>persistent-id decoders are enabled in attribute-map.xml.

Don't do that. You seem to be enabling both the "support the broken
format" rule and the "decode broken format into the expected form for
migration" rule. Pick one (or just flat ignore the broken form and don't
support it). You should absolutely not be using both rules, they're
mutually exclusive by intent. And it's impossible by design to have two
rules that are for the same underlying SAML data.

>     For this one we are in a pickle because we try to choose
>persistent-id and our multi-value algorithm fails. We then have to go
>and set this IDP to key by targeted-id so that it doesn't trip over on
>the "all values in multi-valued persistent-ids much match" requirement.

Stop supporting targeted ID, that would be my suggestion. Enable the
special decoder we provided to turn that into the proper syntax that
should be used in all cases, and use that as the required form that you're
keying off. That was the point of adding it.

>+ urn:oid:1.3.6.1.4.1.5923.1.1.1.10
> + urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Those are just alternate SAML transports for the same thing, and the
former is essentially unneeded unless SAML 1.1 support is required. In no
case should they ever be different anyway.

>In order to try to get a better idea of who is sending what, I'd like to
>change the persistent-id decoders to decode to, say
>"persistent-id-{oasis,oid,mace}" then my keying algorithm could change
>from
>
>"pick persistent-id then targeted-id" to "pick oasis, then oid then
>mace" and I could dispense with targeted-id entirely.

You don't need to split out the various rules to do that, the whole point
is to collapse them all into one and indeed dispense with targeted-id.

>If I'd been more careful when I set things up then this would be
>trivial. However, I already have a bunch of IDP entries in my app which
>think that they're keyed by "persistent-id" and I can't find enough
>information in the logs to know which decoder was used and therefore I
>can't change this to "oasis", "oid" or "mace".

You shouldn't have to, that's a meaningless distinction.

You're not recognizing that the decoding and serialization of the broken
"targeted-id" form is what makes it look "different". It's not different
in any underlying sense, the value part is the same, it's just that it's
scoped with a domain instead of with the the entityID qualifiers.

The special decoder plugin turns the broken scoped form into a serialized
form that looks like the "proper" encodings already serialize into so that
the application doesn't have to care.

>Is there a way to allow attribute-map.xml entries to work where they
>have the same "name" and "nameFormat" entries as a another decoder but a
>different "id"? That way I can continue to use the keys I currently use
>but also gradually capture the {oasis,oid,mace} information.

No, how could it? The same name and nameFormat is by definition the same
thing on the wire. There is no possible way for it to be "different".
You'd be mapping the same data from the same element to two different
things (and you can do that already with the aliases option).

-- Scott