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

[Nicole Harris <harris AT terena.org>]

On 28/11/2014 10:57, Jozef Misutka wrote:
> On 28 November 2014 at 10:05, Nicole Harris <harris AT terena.org> wrote:
>
>> 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.
>>
> Dear Nicole,
>
> thank you for all your detailed comments.
>
> However, I need clarification for this specific point.
> As far as I can see, social IdPs are *not* part of "eduGAIN" (at least I
> cannot see them in http://mds.edugain.org ).
I'm including ProtectNetwork and things like the Feide OpenIdP in this.
>> 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.
>>
> You have to understand that authorisation is not possible using eduGAIN (or
> any other inter-federation I know) in general unless you accept the fact
> that only a very small subset of eduGAIN IdPs would be usable with your SP.
Yes, this should be accepted as this is how edugain works.
> This topic is for another discussion but you can get the idea by looking at
> statistics of released attributes for our SP [1].
> That is one reason why our users have to explicitly sign licenses for
> specific resources and we allow only users that have *at least* one of
> eppn/persistent-id(targeted id)/email attributes set.
>
> Submitters of our data have specific requirements and one of them is that
> only people connected with academic institutions - please do not take it
> literally as we knew that such users can be alumni, visitors etc. - should
> be able to sign the licenses and that is why I initiated this discussion
> after someone from a private company logged to our SP.
> As mentioned in my first email, we do not have a precise definition of
> "academic" but we can safely assume that private companies are *not*
> academic.
>
> My conclusion is that that you are not considering this as "an issue" but
> rather "a feature" and the advice is to filter out suspicious IdPs even
> though the list is dynamic with hundreds of IdPs.
Yes, that is correct.  You could also attempt to convince your home
federation (I assume this is eduID.cz? and that you receive edugain
metadata from them?) to filter these out as they aggregate but that is a
conversation for you and your home federation.
>> I agree that R&S would be a more appropriate route for CLARIN.
>>
> Please do not confuse CLARIN as a whole and particular member SPs inside
> CLARIN project *like us* with our specific requirements.
>
>
>
> [1]  Statistics from our SP https://lindat.mff.cuni.cz/secure/attributes.xml
> show that e.g., affiliation* is not a commonly released attribute. Please
> note that we are constantly asking IdPs to release more attributes to us so
> the statistics would look worse for other SPs. Also note that the summary
> statistics are for all federations we are participating in.
The fact that IdPs are not releasing attributes is an acknowledge
problem and the R&S Entity Category is intended to resolve this for SPs
that identify as "research and scholarship" services.  I think this is a
good match for what you are describing as "academic".  
> Kind regards,
> Jozef
>
>
>
>> 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
>>>
>>>
>>


-- 
Nicole Harris
Project Development Officer
GÉANT Association Amsterdam Office (formerly TERENA)
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Skype: harrisnv
M:+31 64 610 53 95