Forcing Misuse of TransientID in IdP 3.2.

[Sheldon, Nathan I]

Thanks Scott.

On Jan 31, 2017, at 11:50 AM, Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:

Put yours first, with an appropriate activationCondition on it, and it should be fine.

Indeed.  That did it.

Do you have actual proof that it matters? I'd be very dubious of anything that broken even looking at the Format.

I had the same thought, so I tested sending the same attribute value in the NameID but with different format definitions.  None seemed to work unless it was defined as a transient ID.  Grrr.

—

Hey David.

On Jan 31, 2017, at 11:51 AM, IAM David Bantz <dabantz at alaska.edu<mailto:dabantz at alaska.edu>> wrote:

don't you need to add clause to indicate that nameID is used for specific SP(s)? like

Not in this case.  That attribute ID was defined just for this SP, probably because it was easier to do it that way in IdP v2.  I also prefer to make relying party exceptions in the relying-party.xml configuration rather than in the saml-nameid.xml config, just because it’s easier to keep track of all our exceptions (we have plenty).  IdP v3’s new NameID configuration method would certainly allow for more efficient management of NameID encoding of attribute values for existing attribute definitions.  I may end up optimizing/cleaning those attribute definitions before moving to a production environment, depending on time constrains.

----
Nathan Sheldon (nathan.sheldon at ucsf.edu<mailto:nathan.sheldon at ucsf.edu>)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170131/c436f80b/attachment-0001.html>