<div dir="ltr">Anybody who wants to integrate an SP with our IdP is more than welcome, even if it's just your local workstation. However, when it comes to testing applications, I heavily encourage our dev staff to make use of this: <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPBackDoor">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPBackDoor</a><div><br></div><div>That way I don't have to create a ton of test accounts.</div><div><br></div><div>Dave</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 9:18 AM, Michael Dahlberg <span dir="ltr"><<a href="mailto:olgamirth@gmail.com" target="_blank">olgamirth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I recently received a request from our developers. They are working on a site that will be behind a Shibboleth SP and they are doing a lot of the development on their local systems. They would like to setup a Shibboleth SP install on each of their development machines and then proceed to use our campus production Shibboleth IdP for authentication and authorization to their local test site.<div><br></div><div>While I don't mind including the ~10 new sets of metadata into our shib IdP installation, I can't help but think there is a better way of giving them a realistic view of the site that they are developing with regards to the authentication and authorization process.</div><div><br></div><div>Has anyone implemented a better solution to this problem?</div><div><br></div><div>Thanks,</div><div>Mike</div></div>
<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">David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div></div>
</div>