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

[Jaime Pérez Crespo <jaime.perez AT uninett.no>]

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail