Unencrypted NameID

[Cantor, Scott]

> I have not doubt that I'm misunderstanding, documentation seems very
> incomplete so I'm struggling through this at every step.

The documentation simply assumes you know a lot about SAML and has never been written to be approachable without that baseline, that's why most people struggle.

> Ok, so how do I do this?  The vendor is using NameID and wants it to be
> unique, they're recommending it be the email address.

Using email addresses is often a bad idea, and that's not a Shibboleth thing, it's just bad IDM and application practice. It's not really in scope of this list to talk about all the reasons why and the trade offs, but those are things that come from years of experience integrating systems.

Most business integrations tend to rely on internal keys like employee IDs and the like, since they don't have to be globally unique, just unique in a silo.

Email address, despite it being a bad choice, is the de facto standard identifier that happens to be globally unique, that's why people outside higher ed gravitate to it.

Shibboleth prefers the use of SAML Attributes to the NameID element. Vendors are sloppy and don't know what they want most of the time, but requiring NameID isn't unusual, and is the major source of friction using Shibboleth with those use cases.
 
> This suggests that I can override NameID per SP, if so, how do I do this?

https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration

The documentation refers to them as a "custom" NameID. They can be per-SP but they should not be. NameIDs have Formats and a given Format should never be used to carry different data. SPs can request the Format they want, or you have to manipulate the metadata or configuration to ensure the Format desired gets used. You do not want to start creating rules that generate a Format differently by SP, though it's possible.

-- Scott