Associating SP users with specific IdPs

[Peter Schober]

* Robert Lowe <robertmlowe at rmlowe.com> [2013-03-24 17:26]:
> Okay, from my reading of the spec I understand that both NameQualifier and
> SPNameQualifier are optional. I also get the impression that they are
> rarely used—that is, I don't believe I have ever seem them used either in
> examples/documentation, or “in the wild.”

Well, besides those being used (like Tom said), the software can infer
both values from the protocol messages in the sinple case where all
qualifiers have their default values (NQ = IdP; SPNQ = SP).
A reason to explicitly populate those XML attributes would be that the
IdP or SP has changed its entityID at some point, so an additional
indirection would allow the NameID to carry the old values (instead of
breaking logins for everyone, by having new NameIDs for everyone from
the time the changed EntityID propagates.)

> Is there a way for an SP to indicate that it requires them, either
> via metadata or in an AuthnRequest?

AFAIU the problem you brought up (an IdP impersonating another IdP's
subjects) only seems to be possible when those values are in fact
provided, with differing values than those that the SP can infer
anyway. So you'd be concered with the opposite case, when those values
are provided and don't match their defaults.
Which of course is why those XML attributes are there (i.e., sending
them only really makes a difference when they don't match the
defaults), to allow an addtional indirection so that not everything
breaks for subjects if the IdP's or SP's EntityID ever changes.
-peter