Associating SP users with specific IdPs

[Cantor, Scott]

> I am trying to understand how to configure a Shibboleth service provider
> with multiple identity providers, such that each user of the protected
> application is associated with exactly one of the IdPs. In other words, I do not
> want to assume that the IdPs are mutually trusted; assertions about a
> particular user should only be accepted from the appropriate IdP.

There is no way to do that explicitly. Implicitly it's done with scoped identifiers like EPPN that include policy support for limiting who can assert them.

> This seems like it ought to be a common use case, but I can't find a
> straightforward explanation of how to achieve it. Most of the documentation
> I have seen simply suggests adding the metadata for the IdP, and then goes
> on to talk about discovery.

It's not common at all. Federation is only as strong as the weakest IdP. Most federated apps are in general vulnerable to spoofing of users across IdPs. Scoping is the only way to prevent that unless the implementation actually stores the linked accounts locally and can bind them to specific issuers. The SP does nothing like that, since it requires a database. Obviously an application can.

> I also get the impression that "scoped attributes" are somehow related to
> this problem, but it's not clear to me what is the best way to make use of
> them.

They are the solution provided by this implementation, yes.

> Should one require that the IdPs send scoped attributes and then
> somehow filter out attributes that don't have the correct scope?

The SP filters them automatically provided the metadata allows it to do so.

You could also rely on the  NameID construct and its qualifiers and do filtering based on that, along with having flexibility in how you serialize the NameID structure into an identifier to consume.

> Or should
> the IdPs send unscoped attributes and the SP somehow add the appropriate
> scope before passing the attribute to the application?

It does not do that, though of course an application could.

> I'd appreciate any advice about whether any of the above approaches could
> be considered "best practices," or whether there's something else I've
> missed.

I think you're just realizing how federation actually works. No other implementations support scope filtering, and few of them do anything sensible with the NameID either.

-- Scott