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

[NAINI, NIKHIL]

Ok, thank you for the insights on the matter. 

Also, regarding EOL for 3.3.1, would that be true for 3.4.x too as soon as a 3.5.x or a V4 is released?

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, July 31, 2019 2:59 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)

On 7/31/19, 2:42 PM, "users on behalf of NAINI, NIKHIL" <users-bounces at shibboleth.net on behalf of 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.

If "database" is what you want, then you can use a JAAS module that talks to a database, I know they exist. It seems like maybe you're thinking LDAP is the primary option in the IdP, but that is really not true at all. JAAS is the primary vehicle at the moment, even for LDAP. The real alternative is Kerberos because the delivered flow for that has security improvements over the Kerberos JAAS module.

A file module for JAAS is trivial to build if desired, and I have no doubt there's already a JAAS module somewhere that does it already. Or you can spin up a Kerberos KDC on a Linux host in about a minute flat and just use that in either of the two ways it's possible to do that, it takes virtually no setup to do over localhost since there's no security concern there.
 
But it doesn't answer the data question (i.e. what David just posted). An IdP needs attributes, not just authentication. Authentication is largely incidental to the overall setup work. Vendors asking for test accounts are often involved with systems that have to be keyed by managed data such as an employee ID or such, in my experience. So you've just reserved an employee ID too. That's a big deal at a lot of orgs.

They aren't insurmountable issues, but the point is that authentication isn't the problem, it's the data.

-- Scott


--
For Consortium Member technical support, see https://protect2.fireeye.com/url?k=6acce203-364658c8-6accacc2-86fd412dd9f8-2f6b69969e3b6c5e&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