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

[Tomasz Wolniewicz <twoln AT umk.pl>]

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