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

[Nicole Harris <harris AT terena.org>]

On 28/11/2014 15:01, Tom Scavo wrote:
>
> A question for other responders: I'm not getting the connection to
> Research & Scholarship. AFAIK there is nothing in the spec to restrict
> an arbitrary IdP from self-declaring its support for R&S. Am I missing
> something?
There are many different issues are being addressed here so the
conversation is a little confused.  Using R&S answers the question that
CLARIN are struggling to get IdPs to release attributes to them and
provides a possible solution.

It doesn't answer the question "how do I define what an academic
organiation is".  I'm not sure this is solvable, although it is
interesting. 
It doesn't answer the question "how can I make sure that every academic
in the world is connected to me".  I'm pretty sure that definitely isn't
possible.

It is tackling the problem from a different angle - declare the SP a
worthy R&S resource and hopefully it will attract the right customers
with the right attributes. 
>
>
>
> On Fri, Nov 28, 2014 at 8:50 AM, Jaime Pérez Crespo
> <jaime.perez AT uninett.no> wrote:
>> Hi Jozef,
>>
>>> On 28 Nov 2014, at 11:57 am, Jozef Misutka <misutka AT ufal.mff.cuni.cz> 
>>> wrote:
>>> 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.
>> No, you can’t. Peter already mentioned some very good reasons, and I would 
>> like to emphasize them. Universities will definitely fall under the 
>> intuitive notion of “academic organizations”, but they can be private, 
>> that meaning they are to all effects private companies.
>>
>> Another example. Many companies have research and development divisions. 
>> They are still private companies, but also academic organizations as their 
>> main purpose is to do R&D. Telefónica I+D in Spain is a very good example 
>> of this (though I’m unsure whether they are eligible to be part of the 
>> Spanish Federation or not, maybe my former colleagues in RedIRIS can shed 
>> some light on this).
>>
>> So the conclusion would be that private companies can definitely be part 
>> of the “academic world”, that meaning either being educational or research 
>> institutions, and therefore they should not be excluded by Service 
>> Providers targeting academic organizations just because they are private.
>>
>>> 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.
>>
>> This is wrong too. You are basically assuming a one-to-one correspondence 
>> between SAML IdPs and institutions, i.e. every institution has its own 
>> SAML IdP. That assumption is broken. There’s plenty of federations using a 
>> Hub&Spoke architecture that hides all their institutions behind one single 
>> IdP (the hub). Feide is an extremely good example of this, since there’s 
>> only one IdP for *all* the Norwegian institutions. Therefore, if you 
>> exclude the IdP because there’s an institution there you don’t think 
>> belongs to the academic world, you will be excluding *all* the Norwegian 
>> institutions, academic ones too.
>>
>> Unfortunately, filtering based on entity ID is something quite common, 
>> specially among publishers. And I say unfortunately because it’s simply 
>> wrong. The entity ID informs you as an identity consumer about which 
>> trusted partner is offering an assertion on the user’s identity, and that 
>> means exclusively authentication. What you are after (the institution a 
>> user belongs to) is part of the identity, not part of the underlying 
>> protocol. If you want to do authorization in addition, then you need to do 
>> that based on who the user is (what’s his/her role, where does he/she 
>> belong, and so on and so forth), and that means using attributes.
>>
>> So the solution to your problem is not to hand-pick which IdPs you want to 
>> trust. The solution to your problem is to enter the Research and 
>> Scholarship entity category and check the attributes you get to perform 
>> authorization.
>>
>> --
>> Jaime Pérez
>> UNINETT / Feide
>> mail: jaime.perez AT uninett.no
>> xmpp: jaime AT jabber.uninett.no
>>
>> "Two roads diverged in a wood, and I, I took the one less traveled by, and 
>> that has made all the difference."
>> - Robert Frost
>>


-- 
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