<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 7, 2015 at 6:34 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/7/15, 10:54 AM, "users on behalf of Phil Lello" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:phil@dunlop-lello.uk">phil@dunlop-lello.uk</a>> wrote:<br>
<br>
>For scalability/rapid deployment reasons, I would like to have multiple SPs share one set of federated SP metadata.<br>
<br>
</span>That makes it impossible for an IdP to distinguish between services, manage attribute release, etc. That is generally a bad model for everybody but the person trying to avoid work that isn't really all that much work. The Internet has an end to end principle that underlies its value, and proxies violate that model.<br>
<br>
Off soapbox.</blockquote><div><br></div><div>Soapbox is fine with me; there were two scenarios I had in mind, rapid deployment of production environments (where I'll agree it's at best sub-optimal), and development environments where it's desirable to spin up n-m instances that should be identical from an integration perspective. Whilst I agree the avoided work isn't much in principal, my experience is that application development teams are generally separate from the shibboleth team (who are generally under-resourced), which inevitably leads to long delays.<br><br></div><div>Phil<br></div></div></div></div>