skipping duplicate Attribute mapping (same name and nameFormat)

[Andy Bennett]

Hi,

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

Agreed.


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

Here is the appropriate excerpt from my attribute-map.xml

-----
<!-- A persistent id attribute that supports personalized anonymous
     access.
-->

<!-- First, the deprecated/incorrect version, decoded as a scoped
     string:
-->
<Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
           id="targeted-id">
  <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
  <!-- <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
           formatter="$NameQualifier!$SPNameQualifier!$Name"
           defaultQualifiers="true"/>
  -->
</Attribute>

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

<!-- Third, the new version (note the OID-style name): -->
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
           id="persistent-id">
  <AttributeDecoder xsi:type="NameIDAttributeDecoder"
      formatter="$NameQualifier!$SPNameQualifier!$Name"
      defaultQualifiers="true"/>
</Attribute>

<!-- Fourth, the SAML 2.0 NameID Format: -->
<Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
           id="persistent-id">
    <AttributeDecoder xsi:type="NameIDAttributeDecoder"
        formatter="$NameQualifier!$SPNameQualifier!$Name"
        defaultQualifiers="true"/>
</Attribute>
-----


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

Is that correct?


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

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

What would I need to change in the rules above?



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

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.


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

I don't really want to do that in the SP. I'd rather just have the SP
decode everything separately and then I can pick the format I like the
most in the app. In the app it's easy for us to do things on a per IDP
basis.

The trouble with moving to separate decodings is that I don't know which
inputs are mapping to which persistent-id values for the current IDPs
I've seen.





Regards,
@ndy

-- 
andyjpb at knodium.com
http://www.knodium.com/