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

[Mikael Linden <mikael.linden AT csc.fi>]

I second Tom. I can't see how R&S helps Jozef to solve his problem.

I also sympathize Jozef. We should provide scalable mechanisms for SPs 
(better than "read their MRPS") to filter out the IdPs. We have Entity 
categories for SPs, can't we introduce them for IdPs as well? Or use 
eduPersonAffiliation for academics.

We shouldn't shoot down a brave customer when he comes to us and asks us to 
improve our service.

Cheers,
mikael

-----Original Message-----
From: Tom Scavo [mailto:trscavo AT internet2.edu]
Sent: 28. marraskuuta 2014 17:02
To: edugain-discuss AT geant.net
Subject: Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs

A suggestion for Jozef: Do the following thought experiment. Suppose your 
service didn't support federated login, that is, you issued accounts to all 
your users. How would you ensure that your users met the "academic" 
requirement?

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?

Tom



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
>