<div dir="ltr">I understand that AuthnRequest scoping is the proper way to do this, but the SP has to send a list of identity providers that should handle the request. That is fine with SPs where you can manage the integration, but SPs such as Office 365 won't be sending any scoping unfortunately. This leaves me with little choice but to put the IdP id in the POST or Redirect URL.</div><div class="gmail_extra"><br><div class="gmail_quote">On 8 January 2016 at 16:42, Michael A Grady <span dir="ltr"><<a href="mailto:mgrady@unicon.net" target="_blank">mgrady@unicon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 8, 2016, at 9:45 AM, Tom Scavo <<a href="mailto:trscavo@internet2.edu">trscavo@internet2.edu</a>> wrote:<br>
><br>
> On Fri, Jan 8, 2016 at 10:39 AM, Bogdan Albei <<a href="mailto:bogdan.albei@callsign.com">bogdan.albei@callsign.com</a>> wrote:<br>
>> Would multiple IdPs with their own entityIDs mean multiple Shibboleth<br>
>> instances, or is it possible with a single Shibboleth instance?<br>
><br>
> It can go either way but I don't think Shibboleth is the right tool<br>
> for the job. We run a single (modified) instance of simpleSAMLphp that<br>
> does this. FYI, Cirrus Identity developed the instance for us.<br>
><br>
<br>
</span>SimpleSAMLphp (SSP) does lend itself to a bit easier "hacking".  One approach is as Tom suggests above, where you can make a single instance of SSP support a set of "virtual IdPs". Another hacking approach: we have an SP integration with a Proxy IdP we operate where we do support added PATH info for the SSP's SSO endpoint, and where that added PATH info is a code that identifies the specific "home IdP/authn source" for this user. (Where discovery already happened on the SP side, but for a number of reasons we still need the SP's AuthnRequest to go thru the Proxy.) (e.g. At the end of the usual SAMLv2 SSO Redirect endpoint, one adds '/authnsourcecode', and that identifies the authn source for that user, which is not always a SAML IdP. As far as the SP is concerned, the SAMLv2 SSO Redirect endpoint is that full URL.) We used that approach with that SP because it was a model that SP was already using for a different integration.)<br>
<br>
But the Scoping element in the Authn Request is the standards-based way to handle this.<br>
<br>
--<br>
Michael A. Grady<br>
IAM Architect, Unicon, Inc.<br>
<br>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="color:rgb(136,136,136)">Bogdan Albei</span><div style="color:rgb(136,136,136)">Senior Platform Engineer</div><div style="color:rgb(136,136,136)">Callsign Inc.</div><div style="color:rgb(136,136,136)">[C] bogdan</div><div><br></div></div></div></div></div></div></div></div></div></div></div>
</div>