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

[Nicole Harris <harris AT terena.org>]

I'm afraid this analogy doesn't work for many reasons.

Firstly eduroam doesn't apply to "academic" organisations.  You could
perhaps say "educational" but that is a different thing and it is not
well defined in the eduroam documentation either. I've no problem with
the edugain TSG taking a similar stance to the eduroam SG and deciding
any given entity is not appropriate...but forbidding them is
dangerous.

Eduroam is essentially a single service federation - the service of
wifi access. Identity federations have to meet the needs of multiple
different service types with different needs.  We have to cater for a
variety of use cases.

Getting rid of social IdPs will not by default mean the rest are
"academic" IdPs in any sense.

Would you ban IdPs using Google, such as TERENA?

Many services find social IdPs very useful - for example pretty much
all of the TERENA services. If we cannot get these via edugain, where
should we get them from?

If CLARIN want to achieve the process of reaching "every academic in
the world" banning social IdPs becomes counter productive.

So in short banning them would reduce service at a significant number
of services and make edugain less valuable to them, and would not
achieve the result CLARIN wants.

Arguing that identity federations should move to a scenario where
authentication = authorization for any IdP present in metadata is a
very dangerous path to consider IMHO...particularly when we are
catering for subscription services.  I don't think asking SPs to have
proper authorization policies is a scaling problem. It's a security
fact.

I agree that R&S would be a more appropriate route for CLARIN.

Sent from my iPhone

> On 28 Nov 2014, at 08:17, Tomasz Wolniewicz <twoln AT umk.pl> wrote:
>
> Hi Nicole and Josef,
>   I would like to start from another angle, even though it is
> definitely not a crucial point in this discussion. Josef mentioned the
> "academicity" of not only IdPs but also SPs. Any limitation on SP
> participation based on their commercial vs. academic status would of
> course kill the whole idea of building federations, where commercial SPs
> providing (often paid) services to academic community have a major role.
> This is something that we should not discuss and I cannot imagine a use
> case that could justify any limitations. There seem to be use cases for
> R&S entity category and this is something that should take care of all
> possible problems.
>
>  However the main issue are, of course, IdPs. Here, my initial reaction
> was to sympathize with Jozef's views. It is of course very true that
> authentication is not identical to authorization and the you can do
> filtering at your own will etc. However, the very idea of eduGAIN was to
> make federation scale reasonably. When someone tells me that I need to
> start looking at every IdP that may have popped up in the eduGAIN
> metadata then I do not see that this scaling is under control. I may
> indeed end up reading every federation policy and marking those
> federations which I can blindly trust (Polish PIONIER.Id would be a good
> example since it explicitly limits IdP participation to those of
> academic origin) against the ones that need manual verification of IdPs
> (UK Federation would be such an example, I guess).
>
>  While it is pretty obvious that we cannot limit what IdPs belong to a
> particular federation, we may very easily rule that federations are
> obliged to filter their IdPs and export only the "acedemic" ones into
> eduGAIN. It is true that the term "academic" is not precisely defined,
> but it somehow works in eduroam. We have made a lot of fuss when it
> turned out that a Czech public library was providing all its readers
> with eduroam accounts, which they could use world-wide. We felt that
> this was violating the very principles of eduroam, where incidentally
> authentication==authorization. I would not have anything against
> applying similar thinking to eduGAIN.
>
> Tomasz
>
>
> W dniu 2014-11-27 22:22, Nicole Harris pisze:
>> Hi Jozef
>>
>> You do not actually state what your issue is, but I assume the issue is
>> that you do not like the presence of Protect Network in metadata.  The
>> simple answer to that is, filter it out.  Service Providers are not
>> expected to connect to every single IdP present in metadata as we have
>> discussed before.
>>
>> Most federations are absolutely clear that presence in metadata is not
>> equal to access.  It is very important that SPs do NOT authorise access
>> based on presence in metadata, you need to have a policy in place.
>>
>> If you consider the case of an academic publisher, they are obviously
>> only going to give access to those organisations that are paying
>> customers so they filter.  Some filter so that the IdP doesn't appear in
>> discovery, some return an error message saying that access is not
>> permitted, others may permit access to a guest space but not to
>> content.  The approach is in the hands of what works for the SP.
>> Likewise some IdPs may actively chose not to permit access to your
>> service.
>>
>> So you statement is incorrect - edugain does not "allow" private
>> companies to authenticate to the SP - only the SP allows any given IdP
>> to authenticate (and then indeed authorise) and if you are not
>> controlling this, you are doing something wrong.
>>
>> Similarly no federation is ever going to be able to tell you who is an
>> academic, they will only be able to tell you what relationship any given
>> individual has with any given organisation.  There is no globally
>> accepted definition or passable attribute that says "academic" - we can
>> only say "is affiliated with"  - and this of course does not cover
>> accounts controlled by individuals.
>>
>> To answer your question as to why Protect Network is in metadata, it is
>> because some people use it as an IdP of last resort.  There are many of
>> these in federation metadata such as Google, OpenID Providers etc.
>> although I don't actually think many people use Protect Network
>> anymore.  These "last resort" IdPs are only intended to give very basic
>> data so there would not be any point expecting them to provide detailed
>> attributes.  These are social accounts and they are a desirable feature
>> for some federated exchanges.
>>
>> The more appropriate question seems to be does CLARIN have customers
>> that wish to use Protect Network?  Based on the fact that you require
>> the user to be able to prove they belong to an institution (or "be an
>> academic") then the answer would appear to be no.  So again, you need to
>> filter this specific IdP out. If you need help with how to do that, many
>> of the federations should be able to point you to appropriate
>> documentation dependent on the software set-up CLARIN has.
>>
>> Please do not assume that every account in every IdP somehow implies
>> that the user is an academic.  University IdPs can include accounts from
>> everyone from the most venerable professor through UG students to
>> cleaners.  You may be interested in the emerging InAcademia service
>> (https://www.inacademia.org/) that seeks to provide a more simple
>> interface to finding out someone's affiliation but again I must stress
>> this will only tell you that someone is affiliated to a certain
>> organisation in a certain role.
>>
>> I hope that helps
>>
>> Best wishes
>>
>> Nicole
>>
>>> On 27/11/2014 08:34, Jozef Misutka wrote:
>>> Dear all,
>>>
>>> putting my Service Provider (SP) admin hat on I would like to hear your 
>>> opinions on the matter described below and whether it is an issue for 
>>> other SPs as well.
>>>
>>> Let's start with reading 
>>> http://services.geant.net/edugain/About_eduGAIN/Pages/Home.aspx which can 
>>> give the impression that SPs and IdPs inside eduGAIN should have 
>>> "academic" [1] background:
>>> """
>>> eduGAIN is a service developed within the GÉANT Project - a major 
>>> collaboration between European national research and education network 
>>> (NREN) organisations and the European Union.
>>> """
>>> Entities are pushed to eduGAIN by national federations (NFs). Although 
>>> many NFs have " Education and Research", "Academic" or "Science" in their 
>>> name they have their own policies in accepting members.
>>> Simply put, because "eduGAIN" does not have any requirements on the 
>>> published entities in this respect users from e.g., private companies! 
>>> can authenticate to SP.
>>> And this can be a problem for our (or any other) academic SP.
>>>
>>> We want to be available "for all academics of the world" and we thought 
>>> eduGAIN could help us and simplify the process. But because a lot of IdPs 
>>> do not release any or valid attributes we do not know if the 
>>> authenticated user is "academic" or not at the moment. The only way is to 
>>> (regularly) go through http://edugain.org/ technical/status.php , read 
>>> all the Metadata Registration Practice Statement (MPRS) and find out 
>>> which IdPs can join the particular federation. In case a NF allows 
>>> private companies we would have to manually approve academic IdPs from 
>>> that federation.
>>>
>>> Some NFs put categories to published IdPs; however, it is not feasible to 
>>> know all the NFs in detail for every SP.
>>>
>>> Thank you for your input.
>>>
>>> [1] We do not have a precise definition of "academic" but we know that 
>>> private companies are not academic.
>>>
>>>
>>> Kind regards,
>>> ____________________________
>>>
>>> Jozef Misutka
>>> LINDAT/CLARIN CTO
>>> http://lindat.cz
>>> https://lindat.mff.cuni.cz/repository/xmlui/
>
> --
> Tomasz Wolniewicz
>          twoln AT umk.pl        http://www.home.umk.pl/~twoln
>
> Uczelniane Centrum Informatyczne   Information&Communication Technology 
> Centre
> Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
> pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
> tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: 
> +48-693-032-576
>
>
>