NameID configuration per relying party

[Boyd, Todd M.]

So, I'm already filtering the attribute--you're saying I should remove the activationCondition XML from my config so that anybody else that needs this format for NameID can be handled in an easier fashion?


-Todd


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, October 02, 2017 9:09 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: NameID configuration per relying party

> I think part of the issue here is that this RP has provided no 
> metadata, and rather than creating an "open" IdP, I created a metadata 
> file by hand after much excruciating back-and-forth with the vendor. 
> Nonetheless, I do now have it sending campusPermanentId in the NameID 
> of the Subject. The piece I was missing at last was to set the 
> NameIDFormat in the metadata for the RP.

If the use case is for a custom Format based on some existing attribute, then stylistically my advice would be, don't mess with activation conditions to limit it, just apply standard filtering to the attribute itself, and then leave the generator alone. That way you have one place to control data policy. Anything that triggers that Format would be "getting that NameID" but they won't get anything if the attribute isn't released to them, so there's no unexpected behavior.

The purpose of activation conditions in generators is really to deal with broken SPs that require mis-use of a Format such that you need multiple generators configured of a given Format and need them to avoid colliding.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net