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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jozef,

I think there is a some confusion here, maybe because of how your
local federations policy works.

As far as I am aware, noting in eduGAIN suggests the *entities* must
be academic. It only states entities should be *members* of the
(academic) federation. Whatever the rules are for joining a national
(academic) federation is out of scope for eduGAIN. These rules will
vary between federations.

In The Netherlands for example, a guest IdP cannot ever be a member of
the federation, (thus also not a member of eduGAIN via our
federation), but we do have educational sections of Goverment, Defence
and Police as IdPs as these are accredited by the Dutch ministry of
Education and as such eligible. In addition we have IdPs that
represent research departments of commercial companies, like e.g.
Springer, who are also eligible because of the same rule. In The
Netherlands being 'academic' is not the rule for being a federation
member, accreditation by the Dutch ministry of Education is.

I suspect(/hope) the UK federation that publishes protectnetwork has
some reasoning for allowing them in (I must say I was surprised as
well) and this does make me wonder what policy the UK federation in
general has in regard to validating that a person in an IdP is realy
who he claims he is, but that is out of scope for why protectnetwork
is in edugain at all..

Cheers,
Niels

On 28-11-14 11:57, Jozef Misutka wrote:
> 
> 
> On 28 November 2014 at 10:05, Nicole Harris <harris AT terena.org 
> <mailto: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 ).
> 
> 
> 
> 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. 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.
> 
> 
> 
> 
> 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.
> 
> Kind regards, Jozef
> 
> 
> 
> 
> Sent from my iPhone
> 
>> On 28 Nov 2014, at 08:17, Tomasz Wolniewicz <twoln AT umk.pl
> <mailto: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 <mailto: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 <tel:%2B48-56-611-2750>
>> fax:
> +48-56-622-1850 <tel:%2B48-56-622-1850>       tel kom.: 
> +48-693-032-576 <tel:%2B48-693-032-576>
>> 
>> 
>> 
> 
> 


- -- 
Please note:
On January 1st, 2015 SURFnet will move to a new office.
Visiting address: Kantoren Hoog Overborch (Hoog Catharijne)
Moreelsepark 48, 3511 EP Utrecht
Postal address: PO Box 19035, 3501 DA Utrecht
Telephone: +31 88-7873000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUeGTKAAoJECCFeCvee7L1YngP/2yA1RsKN0Dfu8v3FWvXfVaN
jnOaAQ8AUHolzIVGZFMz0w1La7FclMLiAcl6cGO9gGvMGaNeK+6Waem3dpm0aZke
VnBU46C+sRr5Szc+I2iS1Lzu3RxIM2eBDbaJRYl0oe4MZsJTSbz/PYUyKTwNWwjl
ieb8mBf0BbYEkYVHSoBFxl5z0XC/KdOAr6SHPvTWEmB/hYXqvhTsqamamWAilJrc
yirIn8i0su3f1wpyq8iQFnrALt7RGNhtjtDSWPIrOC0VpGPCkTIkMZB0dslyah6y
zWfowRpeLfX4Il+g4GDL30ge+xIqJe0s/fIY8TJYv5TJd1McclN5j3Atltw07x7F
13m91QujzOdC/mKpzasYZwwyqbPBiucMAPj/U0VPMLBUEZsc69gwcen3v/QldhKE
0dZCmH8hD4z6uoI46JJX1kCZ0F/ogEeTIpp0Olup92S9hzc1usil7PXwF3HJsUUs
EKGCxnFWCOXLm+7Vhe+7FyQMnjQP/XtcUqKqTgzqdh1S2s3aLFhseHeNdfMxs2j9
fM8E5kIUkSGIHLpO62EPR3YL/gQEFHxGQVSTSpYU0amsqOvTVtLQNiTqj3Gr5q2Z
I6IOwNvbIG4wyPDmDr3b+VUsCkzgTtryQtj5c3HEhtYEnqq3gLCcUnwlEOmU/wJu
xIWOgiJn51TqPzgWjK2L
=Nx/1
-----END PGP SIGNATURE-----