Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] eduGAIN Access Check: Check federated login for your eduGAIN SP

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive

Re: [eduGAIN-discuss] eduGAIN Access Check: Check federated login for your eduGAIN SP


Chronological Thread 
  • From: Olivier Salaün <olivier.salaun AT renater.fr>
  • To: Niels van Dijk <niels.vandijk AT surfnet.nl>, "edugain-discuss AT geant.net" <edugain-discuss AT geant.net>, refeds AT terena.org
  • Subject: Re: [eduGAIN-discuss] eduGAIN Access Check: Check federated login for your eduGAIN SP
  • Date: Wed, 9 Sep 2015 10:04:47 +0200
  • List-archive: <http://mail.geant.net/pipermail/edugain-discuss/>
  • List-id: "An open discussion list for topics related to the eduGAIN interfederation service." <edugain-discuss.geant.net>

Hello Niels,

Le 08/09/2015 16:13, Niels van Dijk a écrit :
55EEED1B.3050307 AT surfnet.nl">
Nice!

Just tested it with one of my services, and this works well :)
I'm glad you find the service useful.

55EEED1B.3050307 AT surfnet.nl">
2 requests:
- - can I get a slightly more convenient way of seeing username/passwd
and associated attributes?
- - can I download the account details?

I think both could be covered if the Test Accounts page would feature
a CSV or TXT download of the accounts. This would instantly solve the
"Please keep a record of the above user names and passwords" issue ;)
It sounds like a legitimate request; I think we could implement that in a future release

55EEED1B.3050307 AT surfnet.nl">
Also a few questions:
- - are you reassiging ePPNs? I am think here of a case where I would
allow somebody with ePPN 19 AT access-check.edugain.org access, but after
7 days that might be assigned to somebody else?
The service is designed so that ePPNs doesn't get reassigned.

55EEED1B.3050307 AT surfnet.nl">
- - the accounts show: "eduPersonTargetedID: value dynamically generated
by the SP" -> will the give a persistent or a transient value?
The value of the eduPersonTargetedID is a persistentID, as implemented by simpleSAMLphp [1]

55EEED1B.3050307 AT surfnet.nl">
- - The check seems to ignore the SPs attribute retirements from SP
metadata. Is that intentionally?
I assume you meant "attribute requirements" above. eduGAIN Access Check should only those user attributes requested by the SP. Attributes expectations are loaded from the SP SAML metadata (RequestedAttribute XML entries). If you observe a different behavior, please come back to me with details; I will investigate.

55EEED1B.3050307 AT surfnet.nl">
Then a more philosophical question:
Our federation does not like/allow test entities to be published into
eduGAIN, as we would typically want them to think about stuff like
attributes and test that with a testbed like this one *before* they
connect to eduGAIN. We e.g. require an attribute request statment
before a SP can join our federation.

I feel therefore it would make sense to also allow SPs to test their
setup before getting into eduGAIN. This would require a serie to
provide a metadata URL, not select one from existing metadata. What do
you think?
That's exactly the conclusion we drawn within the "Enabling Users" GEANT task. Therefore next release of the Access Check service will be useable within national federations context too, because we had use cases in France and Switzerland already. What will change: some kind of federation selection, different test account templates to meet each federation's requirement.

Regards.

[1] https://simplesamlphp.org/docs/1.12/core:authproc_targetedid
55EEED1B.3050307 AT surfnet.nl">
Many thanks,

Niels

On 08-09-15 15:41, Olivier Salaün wrote:
Hello all

Have you ever wanted to test login on your eduGAIN Service Provider
with different identities (staff, student, researchers) from a
eduGAIN different Identity Provider than your own?

If so, we recommend you to have a look at the "eduGAIN Access
Check" service that allows administrators of eduGAIN SPs to test
federated login of their own service with different user
(attribute) profiles. This is especially useful if the operators of
an eduGAIN service don't have an eduGAIN-enabled account themselves
(e.g. cloud providers or researchers whose institution is not in
eduGAIN yet). But it is also useful in case one wants to test login
from another eduGAIN Identity Provider than the one from his own
institution.

The eduGAIN Access Check provides realistic short-time user
profiles (users with non-ascii names, incomplete attribute sets) to
help SP administrators improve and adapt their eduGAIN-enabled
service.

If you want to try the eduGAIN Access Check service and learn more
about it, find the service and its description at:

<https://access-check.edugain.org/>

Feel also free to let other Service Providers know about the
eduGAIN Access Check; they might find it useful if they consider
joining eduGAIN.

As the service development continues, we are also looking forward
to getting feedback and inputs.

--

--


 
Olivier Salaün
Etudes et projets applicatifs
 
Tél : +33 2 23 23 71 27
Fax : +33 2 23 23 71 11
www.renater.fr
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex


PNG image




Archive powered by MHonArc 2.6.19.

Top of Page