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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Joshua Brodie
Didn't want to hijack the thread on 'Local/Internal IdP Login Account'.

For test accounts -- could 'ImpersonateInterceptConfiguration' be an option - https://wiki.shibboleth.net/confluence/display/IDP30/ImpersonateInterceptConfiguration

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
On 7/31/19, 1:32 PM, "users on behalf of Joshua Brodie" <[hidden email] on behalf of [hidden email]> wrote:

> For test accounts -- could 'ImpersonateInterceptConfiguration' be an option -

Yes, depending on your attribute story. I pitched it here once or twice as an option if we wanted to create test identities in our IDM that didn't have passwords set as a security measure.

But yes, it points out that authentication is really not the issue with test accounts, it's the data that's the problem, and in the end it's all production, not test. Data just has the meaning you choose to give it, and you have to carefully think about it end to end before doing anything, unless it's closely held.

So, no, I would never issue a test account to a vendor in any real sense. Not without an end to end strategy with security controls on the usage to limit it to specific services and a careful plan for what the data would look like.

I just tell vendors that ask that I don't need them to test my system, I need to test theirs. If they need a test account in my IdP to debug their own software, that tells me a great deal about how they do things and what my expectations should be.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

NAINI, NIKHIL
> I just tell vendors that ask that I don't need them to test my system, I need to test theirs.

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 (Apparently CAS SSO has this feature, but I'm not entirely sure about the technical details involved).

From a timeline perspective, I did read the expected completion to IdP V4 is Q4, 2019, but can anyone comment on its progress? 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.

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, July 31, 2019 1:56 PM
To: Shib Users <[hidden email]>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)

On 7/31/19, 1:32 PM, "users on behalf of Joshua Brodie" <[hidden email] on behalf of [hidden email]> wrote:

> For test accounts -- could 'ImpersonateInterceptConfiguration' be an option -

Yes, depending on your attribute story. I pitched it here once or twice as an option if we wanted to create test identities in our IDM that didn't have passwords set as a security measure.

But yes, it points out that authentication is really not the issue with test accounts, it's the data that's the problem, and in the end it's all production, not test. Data just has the meaning you choose to give it, and you have to carefully think about it end to end before doing anything, unless it's closely held.

So, no, I would never issue a test account to a vendor in any real sense. Not without an end to end strategy with security controls on the usage to limit it to specific services and a careful plan for what the data would look like.

I just tell vendors that ask that I don't need them to test my system, I need to test theirs. If they need a test account in my IdP to debug their own software, that tells me a great deal about how they do things and what my expectations should be.
 
-- Scott


--
For Consortium Member technical support, see https://protect2.fireeye.com/url?k=283e002e-74affd98-283e4eef-ac1f6b0e677a-fca57723a59b8e6c&q=1&u=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
On 7/31/19, 2:05 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> 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://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

NAINI, NIKHIL
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 <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, July 31, 2019 2:23 PM
To: Shib Users <[hidden email]>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)

On 7/31/19, 2:05 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, July 31, 2019 2:23 PM
To: Shib Users <[hidden email]>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)

On 7/31/19, 2:05 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
In reply to this post by NAINI, NIKHIL
On 7/31/19, 2:42 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> 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://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 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 <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, July 31, 2019 2:59 PM
To: Shib Users <[hidden email]>
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)

On 7/31/19, 2:42 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
On 7/31/19, 3:27 PM, "users on behalf of NAINI, NIKHIL" <[hidden email] on behalf of [hidden email]> wrote:

> 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?

There won't be a 3.5 but it's always true of minors, and always has been for the life of the project. We have never once supported multiple minor branches at the same time, not in the SP or IdP.

Major releases have overlapping support lifetimes because there are API changes and plugin breakage but that depends greatly on the degree of change and the risk of upgrades, and I don't expect future major releases will have long upgrade periods in comparison to the past. Months at most and not years.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Michels
In reply to this post by Cantor, Scott E.
Am 31.07.2019 um 19:55 schrieb Cantor, Scott:

>
> But yes, it points out that authentication is really not the issue
> with test accounts, it's the data that's the problem, and in the end
> it's all production, not test. Data just has the meaning you choose
> to give it, and you have to carefully think about it end to end
> before doing anything, unless it's closely held.
>
> So, no, I would never issue a test account to a vendor in any real
> sense. Not without an end to end strategy with security controls on
> the usage to limit it to specific services and a careful plan for
> what the data would look like.

Here
https://doku.tid.dfn.de/de:shibidp3testzugang_fuer_externe_admins
are two technical solutions for restricting an account to a specific
service via activation conditions in the data connectors. The web page
is in German, but the code examples should be understandable. Feel free
to ask me. Comments are welcome.

Best regards,
Thorsten

--
Thorsten Michels
RHRK
TU Kaiserslautern
Postfach 3049
67653 Kaiserslautern
Tel.: 0631/205-2443
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Peter Schober
* Thorsten Michels <[hidden email]> [2019-08-01 08:12]:
> Here
> https://doku.tid.dfn.de/de:shibidp3testzugang_fuer_externe_admins
> are two technical solutions for restricting an account to a specific service
> via activation conditions in the data connectors.

Thanks for sharing. I don't see that scaling too well with having to
manage userid-entity pairs for each SP that wants this but maybe those
arrangements are all short-lived by their nature.

I'd have preferred for the IDP to terminate processing for any other
SPs accessed instead of merely send them along but w/o attributes.
Currently you risk subject still having access to all SPs that don't
perform authorization (or charge per subject or whatever). But that
too may be an edge case.

As for the data: Does your shibgast_resolver_condition.xml resolver
consist of all static attribute definitions? That way it would be
fully self-contained in the IDP.
Using an embedded H2 database has been my sqlite alternative for Java
applications of late, which seems to work well. So pointing that
seperate resolver to a local H2 database file could be an alternative,
I guess?

Though in your case the guest account still has to be created in the
IDM system (or authn system used by the IDP), at least you don't
mention anything else.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Michels
Am 01.08.2019 um 11:15 schrieb Peter Schober:
> * Thorsten Michels <[hidden email]> [2019-08-01 08:12]:
>> Here
>> https://doku.tid.dfn.de/de:shibidp3testzugang_fuer_externe_admins
>> are two technical solutions for restricting an account to a specific service
>> via activation conditions in the data connectors.
>
> Thanks for sharing. I don't see that scaling too well with having to
> manage userid-entity pairs for each SP that wants this but maybe those
> arrangements are all short-lived by their nature.

A short-lived access was the intention to this solution.

> I'd have preferred for the IDP to terminate processing for any other
> SPs accessed instead of merely send them along but w/o attributes.
> Currently you risk subject still having access to all SPs that don't
> perform authorization (or charge per subject or whatever). But that
> too may be an edge case.

That's right. At the moment I don't connect to any SP that doesn't at
least check for "member@...".

> As for the data: Does your shibgast_resolver_condition.xml resolver
> consist of all static attribute definitions? That way it would be
> fully self-contained in the IDP.

If the question is: "Has the shibgast_resolver_condition.xml to be
referenced in every DataConnector?", then yes, even the static ones.

> Using an embedded H2 database has been my sqlite alternative for Java
> applications of late, which seems to work well. So pointing that
> seperate resolver to a local H2 database file could be an alternative,
> I guess?
>
> Though in your case the guest account still has to be created in the
> IDM system (or authn system used by the IDP), at least you don't
> mention anything else.

That's right.

Best regards,
Thorsten

--
Thorsten Michels
RHRK
TU Kaiserslautern
Postfach 3049
67653 Kaiserslautern
Tel.: 0631/205-2443
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Peter Schober
In reply to this post by Joshua Brodie
* Joshua Brodie <[hidden email]> [2019-07-31 19:32]:
> Didn't want to hijack the thread on 'Local/Internal IdP Login Account'.
>
> For test accounts -- could 'ImpersonateInterceptConfiguration' be an option

While not suitable for all use-cases one might want test accounts for
it's still worth mentioning: https://access-check.edugain.org/

TL;DR: If an SP is available via eduGAIN this special-purpose
self-service IDP can be used with multiple different data profiles
(with affiliations, without, permutations thereof, etc.) by anyone who
can receive email sent to that SP's ContactPerson/@EmailAddress in
Metadata.
I.e., this method does not involve any changes at your IDM system or
IDP and allows any SP admin to test their own SP with different data
profiles -- and only their own SP.

Source code is available in two "eduGAIN Access Check" respositories
at https://code.geant.net/stash/repos?visibility=public

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Peter Schober
In reply to this post by Thorsten Michels
* Thorsten Michels <[hidden email]> [2019-08-01 11:29]:
> > As for the data: Does your shibgast_resolver_condition.xml resolver
> > consist of all static attribute definitions? That way it would be
> > fully self-contained in the IDP.
>
> If the question is: "Has the shibgast_resolver_condition.xml to be
> referenced in every DataConnector?", then yes, even the static ones.

I misread the documentation to describe conditionally loading another
attribute resolver file but I see now that it does not (it's only
loading the conditions bean).

(The above was my speculation that the test data to be used with the
test subject could be minted within that extra attribute resolver
using static data connectors, but that's also not what you're doing:
Since you're adding test accounts to the IDM system for authentication
anyway I guess you're also managing their data there.)

So this isn't an answer to the current question about how or where
(not) to add test accounts, but instead provides some additional
assurance that no attributes will be asserted to SPs /other/ than the
ones configured for the test userid.

Sorry for the confusion,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Lipscomb, Gary
In reply to this post by Thorsten Michels
We do this at the IdP with an intercept. Any account that is not classified as a "University Member" gets an "Access Denied" message and is blocked completely from SSO.

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Thorsten Michels
Sent: Thursday, 1 August 2019 19:29
To: [hidden email]
Subject: Re: Test Accounts (Per -- Local/Internal IdP Login Account)<snip>


[GL] <Snip>

That's right. At the moment I don't connect to any SP that doesn't at
least check for "member@...".

--
Thorsten Michels
RHRK
TU Kaiserslautern
Postfach 3049
67653 Kaiserslautern
Tel.: 0631/205-2443
[GL] </Snip>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]