skipping duplicate Attribute mapping (same name and nameFormat)

Andy Bennett andyjpb at knodium.com
Thu Sep 4 08:04:53 EDT 2014


Hi,

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

When our app first sees a login for a particular SP it decides whether
to use persistent-id or targeted-id as the key for our "shadow user
account". It looks for persistent-id first and then targeted-id.

Some IDPs send multivalued persistent-ids and this is causing us
problems that we'd like to fix.



We see three types of IDP who send more that one "id":

 + sends different targeted-id and persistent-id

     For this we just use persistent-id and all is well.


 + sends single valued targeted-id and bi-valued persistent-id, all the same

     When we receive a multi-valued persistent-id we split it into the
values, assert them equal then pick one so this case works fine.


+ 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

     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.



Now, there are three types of thing which get decoded to "persistent-id":

 + urn:mace:dir:attribute-def:eduPersonTargetedID
 + urn:oid:1.3.6.1.4.1.5923.1.1.1.10
 + urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

... and one type of thing which gets decoded to "targeted-id":

 + urn:mace:dir:attribute-def:eduPersonTargetedID


As the targeted-id decoder appears before the persistent-id decoder we
see "skipping duplicate Attribute mapping (same name and nameFormat)" in
the logs for the urn:mace:dir:attribute-def:eduPersonTargetedID
persistent-id decoder.




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.


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


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.





Thanks for your help.



Regards,
@ndy

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



More information about the users mailing list