<div dir="ltr">Even if you are able to somehow add test accounts outside your normal user account repository, that will not be a very robust test of your (real) users' access to the service. You'd presumably have different data connector configuration, likely different attribute resolvers so possibly different attribute names and values, and a different workflow for modifying end user accounts in case of issues. As others noted, it's an incomplete user account repository if it cannot include (possibly short-lived) test accounts for your and similar needs. <div><br></div><div>David Bantz</div><div>UA OIT IAM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2019 at 10:42 AM NAINI, NIKHIL <<a href="mailto:NAINI@mailbox.sc.edu">NAINI@mailbox.sc.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When I meant a local instance, I was referring to a local database/file storage option (on the Shib server) rather than utilizing the LDAP option for authentication, did not mean to create a whole new local instance of Shib and asking the apps to trust/connect to it. <br>
<br>
-----Original Message-----<br>
From: users <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>> On Behalf Of Cantor, Scott<br>
Sent: Wednesday, July 31, 2019 2:23 PM<br>
To: Shib Users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><br>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)<br>
<br>
On 7/31/19, 2:05 PM, "users on behalf of NAINI, NIKHIL" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:NAINI@mailbox.sc.edu" target="_blank">NAINI@mailbox.sc.edu</a>> wrote:<br>
<br>
> I very much share the thought process, but the application (team) <br>
> requesting the integration either gives them an admin account or keeps <br>
> pestering us to provide a test account. To get out of this endless <br>
> loop for every new integration, I thought it might be easier to just <br>
> get a dummy account with dummy data setup on a local instance<br>
<br>
How will you convince an application to trust that local instance, if it means what I'm assuming it means? And if you don't have to because you don't have a backchannel flow and it's running with the same key as production, it's not anything but another production instance that had better not be playing fast and loose with what it's doing.<br>
<br>
> (Apparently CAS SSO has this feature, but I'm not entirely sure about the technical details involved).<br>
<br>
They aren't technical issues, it's really semantics.<br>
<br>
> We're considering upgrading from 3.3.1 to 3.4.4, might just wait for V4 to show up if that's gonna be before Dec 2019.<br>
<br>
That would not be a good decision. 3.3.x was end of life the day 3.4.0 was released. Minor updates are not just enhancements to deploy optionally.<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
For Consortium Member technical support, see <a href="https://protect2.fireeye.com/url?k=d72a1921-8bb82533-d72a57e0-0cc47ad9c00a-2e53cc0cab389eb6&q=1&u=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg" rel="noreferrer" target="_blank">https://protect2.fireeye.com/url?k=d72a1921-8bb82533-d72a57e0-0cc47ad9c00a-2e53cc0cab389eb6&q=1&u=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>