Test Accounts (Per -- Local/Internal IdP Login Account)

[IAM David Bantz]

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.

David Bantz
UA OIT IAM

On Wed, Jul 31, 2019 at 10:42 AM NAINI, NIKHIL <NAINI at mailbox.sc.edu> wrote:

> 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.
>
> -----Original Message-----
> From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
> Sent: Wednesday, July 31, 2019 2:23 PM
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)
>
> On 7/31/19, 2:05 PM, "users on behalf of NAINI, NIKHIL" <
> users-bounces at shibboleth.net on behalf of NAINI at mailbox.sc.edu> wrote:
>
> > I very much share the thought process, but the application (team)
> > requesting the integration either gives them an admin account or keeps
> > pestering us to provide a test account. To get out of this endless
> > loop for every new integration, I thought it might be easier to just
> > get a dummy account with dummy data setup on a local instance
>
> 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.
>
> > (Apparently CAS SSO has this feature, but I'm not entirely sure about
> the technical details involved).
>
> They aren't technical issues, it's really semantics.
>
> > 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.
>
> 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.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://protect2.fireeye.com/url?k=d72a1921-8bb82533-d72a57e0-0cc47ad9c00a-2e53cc0cab389eb6&q=1&u=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190731/366f0b07/attachment.html>