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

Cantor, Scott cantor.2 at osu.edu
Wed Jul 31 14:59:27 EDT 2019

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

More information about the users mailing list