Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs


Chronological Thread 
  • From: Nicole Harris <harris AT terena.org>
  • To: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs
  • Date: Fri, 28 Nov 2014 16:11:12 +0000
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>

On 28/11/2014 15:57, Mikael Linden wrote:
> We shouldn't shoot down a brave customer when he comes to us and asks us to
> improve our service.
No-one is trying to shoot anyone down, we are trying to help by
explaining the problem in its wider context - I'm afraid this can only
be done through the conversations we are having here. I'm sure we are
all focused on improving edugain, but it has to be an actual
improvement, not something that we cannot either coherently deliver or
that ends up breaking the service for other customers. Hopefully these
conversations will reach a solution - and I can see that Leif has
already thrown something in to the pit :-)
>
> 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
>>
>


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






Archive powered by MHonArc 2.6.19.

Top of Page