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

[Niels van Dijk <niels.vandijk AT surfnet.nl>]

Hi Olivier,

Thanks for your answers, all clear and usefull.

We would also be interested to look into using a copy of the software for 
local uses.

Cheers,
Niels


----- Original Message -----
> From: "Olivier Salaün" <olivier.salaun AT renater.fr>
> To: "niels" <niels.vandijk AT surfnet.nl>, edugain-discuss AT geant.net, 
> refeds AT terena.org
> Sent: Wednesday, 9 September, 2015 10:04:47
> Subject: Re: [eduGAIN-discuss] eduGAIN Access Check: Check federated login 
> for your eduGAIN SP

> Hello Niels,
> 
> Le 08/09/2015 16:13, Niels van Dijk a écrit :
>> Nice!
>>
>> Just tested it with one of my services, and this works well :)
> I'm glad you find the service useful.
> 
>> 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
> 
>> 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.
> 
>> - - 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]
> 
>> - - 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.
> 
>> 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
>> 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 <http://www.renater.fr>
>       RENATER
> 263 Avenue du Gal Leclerc
> 35042 Rennes Cedex