<div dir="ltr">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 <b>not</b> want to assume that the IdPs are mutually trusted; assertions about a particular user should only be accepted from the appropriate IdP.<div>
<br></div><div>This seems like it ought to be a common use case, but I can&#39;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.<br clear="all">
<div><br></div><div style>One approach I can imagine would be to punt the problem to the application. That is, the application would need to use <font face="courier new, monospace">Shib-Identity-Provider</font> in combination with one of the mapped attributes to identify the user. However, this seems to go against the idea of isolating the application from the authentication mechanism.<br>
</div><div style><br></div><div style>I also get the impression that “scoped attributes” are somehow related to this problem, but it&#39;s not clear to me what is the best way to make use of them. Should one require that the IdPs send scoped attributes and then somehow filter out attributes that don&#39;t have the correct scope? Or should the IdPs send unscoped attributes and the SP somehow add the appropriate scope before passing the attribute to the application?</div>
<div style><br></div><div style>I&#39;d appreciate any advice about whether any of the above approaches could be considered “best practices,” or whether there&#39;s something else I&#39;ve missed.</div><div><br></div>-- <br>
Best regards,<br><br>Robert Lowe<br><a href="http://notability.rmlowe.com/" target="_blank">http://notability.rmlowe.com/</a>
</div></div>