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

[Peter Brand <peter.brand AT univie.ac.at>]

* Peter Brand <peter.brand AT univie.ac.at> [2022-05-16 09:09]:
> * Lukas Hämmerle <lukas.haemmerle AT switch.ch> [2022-05-16 08:48]:
> > What is eduGAIN's current official policy and best-practice in terms of
> > guest and open Identity Providers where just anyone can create an account?
> 
> See the discussion from the thread "Test and Guest Identity Providers
> in eduGAIN" started by someone named Lukas Hämmerle back 2013 CE. ;)

Since some people asked about this off-list:
Please find the referenced thread attached to this email in MIME
format which is hopefully somewhat readable with most mail user
agents.

TL;DR: We removed everything from the eduGAIN policy that would have
prevented this; it's good to remind ourselfs of the differences
between authentication and authorisation/attributes; and finally some
IDPs are being run in a way that's indiscernable from such "open" IDPs
(by allowing guest registration and consequently authentication).
So SWITCH eduID should pose no new or additional threat to anything
and the long and hard way ahead of us to improve the state of affairs
is assurance, of course.

Best,
-peter

--- Begin Message ---

• From: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• To: edugain-tsg AT geant.net
• Subject: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 06 Nov 2013 17:00:46 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: SWITCH

Hello all

Looking at the Identity Providers listed in the production eduGAIN
metadata (mds.edugain.org), I noticed a few aspects that I think are
worth discussing:

* There are several IdPs with "test", "preprod", "beta" in their display
names. It could be that just the names of these IdPs are not up-to-date
but at least in one case, there are even two IdPs listed for the same
organisation (one "test" and one "pre-pod").

* There currently is at least one Identity Provider in eduGAIN that
allows any user with a valid email address to create an account.


My questions therefore are:

* Do you think it is ok to have test/prepod/beta IdPs in eduGAIN?
Is this a problem?
- If so, should there be a rules/recommendation for federation
operators on this subject?

* Do you think it is ok to have Identity Providers in eduGAIN that
allow any users with a valid email address to create an account?
- What if these IdPs allow only creating accounts if the user
has an email address from a known university/research
institution in a particular country?
- What if the accounts are created for example by the administrators
of an (academic) research project?



Best Regards
Lukas

--
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT GN3plus Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch


--- End Message ---

--- Begin Message ---

• From: Mikael Linden <mikael.linden AT csc.fi>
• To: Lukas Hämmerle <lukas.haemmerle AT switch.ch>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 6 Nov 2013 18:17:26 +0200 (EET)
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

>My questions therefore are:
>
>* Do you think it is ok to have test/prepod/beta IdPs in eduGAIN?
> Is this a problem?

Clause 1 of eduGAIN policy declaration[1] says:

"The federation...
1. It will publish technical descriptions of networked computers that act
as AAI endpoints (for example to
provide the functions of identity provider, attribute provider or service
provider) (“the Entities”) which have been
validated for use in the Federation according to its normal operational
standards."

I don't think it is appropriate to have test/prepod/beta IdPs in eduGAIN
unless having them on-board qualifies to the normal operational standards
of the participant federation that has exposed them to eduGAIN.

>* Do you think it is ok to have Identity Providers in eduGAIN that
> allow any users with a valid email address to create an account?

I hope we soon get a common LoA framework to allow SPs filter out those if
they want.

>Best Regards
>Lukas

Cheers
Mikael

[1]
http://www.geant.net/service/eduGAIN/resources/Documents/GN3-10-327%20eduG
AIN_policy_declaration%20v2.0.pdf


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 6 Nov 2013 17:25:51 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

* Lukas Hämmerle <lukas.haemmerle AT switch.ch> [2013-11-06 17:02]:
> * There are several IdPs with "test", "preprod", "beta" in their display
> names. It could be that just the names of these IdPs are not up-to-date
> but at least in one case, there are even two IdPs listed for the same
> organisation (one "test" and one "pre-pod").

Cf. the thread "Test entities in production federation" from Feb this
year, started by Olivier.

> * There currently is at least one Identity Provider in eduGAIN that
> allows any user with a valid email address to create an account.

How is that worse than the account issuing practices at, say, Univie
(not yet eduGAIN enabled; used as an examlpe to avoid bad-mouthing
some other institution), where anyone can create an accout for
any/thing/ which in turn will be able to succesfully /authenticate/ at
the institutional SAML IdP?

Authentication should not be confused with authorization (or someone's
idea of identity vetting). Not inside a single institution, not in a
federation. Not surprisingly also not in interfederation scenarios.

While self-registration IdPs do pose the problem of impersonation (me
creating an account as someone named "Lukas Hämmerle") -- e.g. if the
application only shows the displayName but not the ePPN -- that's not
fundamentally different from two institutional IdPs having two (or
more) individuals with the same legal name and displayName.
(I.e., the displayName alone is never enough to establish trust in an
electonic identity.)

ACOnet also runs such an IdP but we currently don't export it to
eduGAIN (yet, <smiley/>).
I think doing that shouldn't be a problem, though, as it will only
remind people of the difference between authentication and authorization:
Such an IdP should never be able to issue entitlements (or
affiliations, IMO) without additional checks done on the identities.

So I would not encourage the expectation that anything that can
authenticate anywhere in an eduGAIN-exported IDP is more than just a
random account (which basically is what a self-registration IdP
provides).
-peter


--- End Message ---

--- Begin Message ---

• From: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Thu, 07 Nov 2013 17:14:08 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: SWITCH

On 06.11.13 17:17, Mikael Linden wrote:
> I don't think it is appropriate to have test/prepod/beta IdPs in
> eduGAIN unless having them on-board qualifies to the normal
> operational standards of the participant federation that has exposed
> them to eduGAIN.

I agree. However, if I remember correctly there are federations like
UKAMF that have all entities, test and prod, in one single metadata file
not distinguishing between the two. So, in their case, this would be in
line with the policy declaration.


On 06.11.13 17:25, Peter Schober wrote:
> Cf. the thread "Test entities in production federation" from Feb this
> year, started by Olivier.

Thanks, I missed that thread :-)

The impression I got from that thread and some of the recent reponses is
that in general, Test SPs are not much of an issue for most people
because they often are production services that allow to "test"
federated login.

Test IdPs are more controversial because:

* They show up in Discovery Service unless extra measures are taken to
hide them (usability issue)
* They make a bad impression on people first looking at "what is in
eduGAIN") (reputation issue)
* They could potentially allow users accessing services with dummy
identities with too many/wrong attributes (security issue)

On the other hand, if I understood Ian Young correctly he considers
primarily the first point to be an issue and suggests introducing an
entity category attribute to make certain (test) IdPs "less discoverable".

As was noted by Rhys and others, there is the general difficulty to
clearly categorize/identify test IdPs. Just looking at their display
name/dns entry might indeed not be sufficient to say whether this really
is a test IdP. On the other side, in order to address at least the first
two points looking at these two pieces of information might already be
sufficient if one wants to enforce/police the eduGAIN OT recommendation
("in our joining description we specifically state that no
non-production services should be put into MDS,"). As with food and
cloths, it's mostly the label ("it's organic therefore it must be good")
and brand ("it's Kellog's therefore it must be good") that are
important. Hardly anyone reads the actual list of ingredients :-)


> How is that worse than the account issuing practices at, say, Univie
> (not yet eduGAIN enabled; used as an examlpe to avoid bad-mouthing
> some other institution), where anyone can create an accout for
> any/thing/ which in turn will be able to succesfully /authenticate/ at
> the institutional SAML IdP?

It's probably equally bad in case *really* anyone (including me as a
non-staff/non-student of Uni Wien) could create such an Uni Wien account
for me or somebody else. But that is hopefully not what is the case.


> So I would not encourage the expectation that anything that can
> authenticate anywhere in an eduGAIN-exported IDP is more than just a
> random account (which basically is what a self-registration IdP
> provides).

Where I also see a problem is not necessarily only that somebody else
can create an account with displayName "Lukas Hämmerle". I might not
even care so much that somebody could create an account at a Guest IdP
having mail=lukas.haemmerle@switch (but I still hope that this is not
possible because most guest IdPs validate the email address).

My fear concerns also the affiliation (attribute) of a guest account.
eduGAIN, as the name implies, was created for higher education and
research. The same is the case for eduroam. So, IMHO we generally want
to make sure to keep out other (e.g. commercial) users because the label
of these two infrastructures says "contains only education/research
people". This gives us some power when convincing certain service
providers to make use of a federation/eduGAIN. At least it does on a
federation level.

However, the assumption that only edu-people are part of eduGAIN gets
violated if just anybody can create an identity at a Guest IdP that is
part of eduGAIN. I know that it's unrealistic to expect that all
identities in eduGAIN are 100% education/research-related but I think we
still should try not opening the door to just anybody.

Best Regards
Lukas


--
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT GN3plus Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Thu, 7 Nov 2013 19:03:20 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

Hi Lukas,

Thanks for summarizing parts of the previous discussion!
Not sure this isn't more of a topic for the aptly named
edugain-discuss mailing list, but maybe a policy change (stricter
rules for entity eligibility) is the potential outcome of this, so
I'll continue here.

* Lukas Hämmerle <lukas.haemmerle AT switch.ch> [2013-11-07 17:16]:
> On 06.11.13 17:17, Mikael Linden wrote:
> > I don't think it is appropriate to have test/prepod/beta IdPs in
> > eduGAIN unless having them on-board qualifies to the normal
> > operational standards of the participant federation that has exposed
> > them to eduGAIN.
>
> I agree. However, if I remember correctly there are federations like
> UKAMF that have all entities, test and prod, in one single metadata file
> not distinguishing between the two. So, in their case, this would be in
> line with the policy declaration.

Fyi, ACOnet also has test entities (IdPs) in the production trust
fabric. Not that we have many of those (3, I think) or export them to
eduGAIN, making this an internal matter for ACOnet.
(Personally I wouldn't export them unless I heared a very good
explanation what specifically "testing interfederation" meant to them,
and why that needed to happen in the production aggregate.)

> > How is that worse than the account issuing practices at, say, Univie
> > (not yet eduGAIN enabled; used as an examlpe to avoid bad-mouthing
> > some other institution), where anyone can create an accout for
> > any/thing/ which in turn will be able to succesfully /authenticate/ at
> > the institutional SAML IdP?
>
> It's probably equally bad in case *really* anyone (including me as a
> non-staff/non-student of Uni Wien) could create such an Uni Wien account
> for me or somebody else. But that is hopefully not what is the case.

Not at Univie, no. Still there are hundreds or thousands of accounts
registered there which do not represent members of the institution,
but are merely created by members of the institution (for someone
else). Someone could create accounts for all their friends and
business partners and their friends etc, which does not make these
accounts (or their holders) edu* in any sense. That would be an
invalid, albeit common, simplification, possibly partially responsible
for leading resource providers to forgo authorization (since "everyone
authenticated at that IdP will likely be edu*-related and is hence
authorized".).

> My fear concerns also the affiliation (attribute) of a guest account.

Sure (cf my previous email). If I had not said this before: If there
is an IdP in eduGAIN that issues eduPerson(Scoped)Affiliation values
for accounts which were purely created in self-service online,
involving no further/human checking, that IdP is lying and should be
prevented from showing up in eduGAIN (or it's home federation, for
that matter), IMO.
I don't think there's room in /any/ of the eduPersonAffiliation values
for "unknown entity which has signed up for an account".

Our own "Open" IdP could issue affiliations (it does not at this time)
and entitlements (it already does), but those are enabled only after
specific checking procedures (for the main entitlements used uploading
of photo ID and manual checking of that by Univie personnel is required).

> eduGAIN, as the name implies, was created for higher education and
> research. The same is the case for eduroam. So, IMHO we generally want
> to make sure to keep out other (e.g. commercial) users because the label
> of these two infrastructures says "contains only education/research
> people". This gives us some power when convincing certain service
> providers to make use of a federation/eduGAIN. At least it does on a
> federation level.
>
> However, the assumption that only edu-people are part of eduGAIN gets
> violated if just anybody can create an identity at a Guest IdP that is
> part of eduGAIN. I know that it's unrealistic to expect that all
> identities in eduGAIN are 100% education/research-related but I think we
> still should try not opening the door to just anybody.

I think you're taking the service name(s) too literal (which, as an
aside, is why InCommon is a good name, because it doesn't say /what/
those in InCommon have in common).
That same sentiment has been brought forward in the eduroam space
(AFAIK), though, so you're not alone with this. The New Owners of
Everything (eduroam, eduGAIN, TERENA, GEANT, DANTE,...) may well clean
all that up, who knows.
But the eduroam case is different, IMO, because eduroam SPs do not
perform authorization based on data about the subject, provided by the
IdP. If you're authenticated you're authorized, for the most part.

Being able to prevent certain entities from showing up in discovery
services is a perfectly reasonable thing and we could work on making
that possible. That's something entirely different than wanting to
rule out large parts of our constituency from eduGAIN participation
(which is what a strict reading of "edu*" would probably lead to).

I still maintain that services not performing /any/ kind of
authorization should ask themselfs why they insist on doing that. A
simple check of affiliations will weed out /any/ such identities.

I don't see why we should prevent "open" IdPs, or "IdPs of last
resort", from entering eduGAIN (though we might not need many of those
either), only to save a service that has a problem with such accounts
from implementing /trivial/ authorization, which will also be needed
for protecting against certain accounts from institutional IdPs
anyway.

But then again you're not talking about SPs having problems with that
(are you?), only with the "appearance"?
-peter


--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: "Peter Schober" <peter.schober AT univie.ac.at>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 10:44:31 +0100
• Organization: Srce

Peter,

But the eduroam case is different, IMO, because eduroam SPs do not
perform authorization based on data about the subject, provided by the
IdP. If you're authenticated you're authorized, for the most part.

Hm, that is not entirely true.

When it comes to the (current) use of attributes delivered by the IdP, you're right. Still let me remind you on possible use of CUI attribute (currently recommended by the European eduroam Policy)

Also by definition authorisation in eduroam is done by the SP. So, SP has the right to blacklist users (even realms) in case of an incident.

Regards

Miro



--- End Message ---

--- Begin Message ---

• From: Mikael Linden <mikael.linden AT csc.fi>
• To: "Peter Schober" <peter.schober AT univie.ac.at>, <edugain-tsg AT geant.net>
• Subject: RE: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Mon, 11 Nov 2013 16:01:00 +0200 (EET)

Hi Peter,

>From: Peter Schober [mailto:peter.schober AT univie.ac.at]
>Sent: 7. November 2013 20:03

>If I had not said this before: If there is an IdP in eduGAIN that issues
>eduPerson(Scoped)Affiliation values for accounts which were purely
created
>in self-service online, involving no further/human checking, that IdP is
>lying and should be prevented from showing up in eduGAIN (or it's home
>federation, for that matter), IMO.

Due to strong requests from the community, in the recent eduGAIN policy
update (effective 30th September) all behavioral rules for providers were
removed from the eduGAIN policy.

In the Policy Declaration there is still the following item which may help
you: "5. It will provide such assistance to other Participating
Federations as they may reasonably request concerning the publication or
use of Entity Descriptions."

I still hope the issue of test entities and self-asserted attributes is
going to be solved by a LoA specification. Otherwise, eduGAIN is too
difficult for the Service Provider communities to use and they will find
something else (Google or issue local uids/pwds). Unfortunately, I can't
see much happening on LoA in eduGAIN.

Mikael (eduGAIN policy subtask leader)

>-peter


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Mon, 11 Nov 2013 15:52:34 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

* Mikael Linden <mikael.linden AT csc.fi> [2013-11-11 15:01]:
> >If I had not said this before: If there is an IdP in eduGAIN that
> >issues eduPerson(Scoped)Affiliation values for accounts which were
> >purely created in self-service online, involving no further/human
> >checking, that IdP is lying and should be prevented from showing up
> >in eduGAIN (or it's home federation, for that matter), IMO.
>
> Due to strong requests from the community, in the recent eduGAIN
> policy update (effective 30th September) all behavioral rules for
> providers were removed from the eduGAIN policy.

The whole concept of federation crucially depends on IdPs not
willfully (or carelessly) asserting bogus data.
As such, if there were in fact such an IdP as *ficticiously* described
above (one that issued ePSA values for self-registered accounts
without any checking), that would indeed do us all (including
federations outside eduGAIN) a big disservice, IMO.

Note that I don't know whether the unnamed "open" IdP in question
actually issues entitlements or affiliations that way. If not I
personally don't have a problem with that (as I don't see how that'd
be any worse than many institutional IdPs).

I just wanted to try to tease out what I or we would still find
acceptable (no matter what the current policy says), where the actual
pain points or problems are and whether we in fact disagree about this
fundamentally. (I did not think so originally but will leave it for now.)

> I still hope the issue of test entities and self-asserted attributes is
> going to be solved by a LoA specification. Otherwise, eduGAIN is too
> difficult for the Service Provider communities to use and they will find
> something else (Google or issue local uids/pwds). Unfortunately, I can't
> see much happening on LoA in eduGAIN.

Not sure that's still the same discussion. At least I doubt Google
accounts (self-asserted without any institutional checking, AFAIK)
will be seen as an improvement by those having problems with the
existence of "open" IdPs within eduGAIN.
-peter


--- End Message ---

--- Begin Message ---

• From: Mikael Linden <mikael.linden AT csc.fi>
• To: "Peter Schober" <peter.schober AT univie.ac.at>
• Subject: RE: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Mon, 11 Nov 2013 16:58:34 +0200 (EET)

>The whole concept of federation crucially depends on IdPs not willfully
(or carelessly) asserting bogus data.

Agreed.

>At least I doubt Google accounts (self-asserted without any institutional
checking, AFAIK) will be seen as an improvement by those having problems
with the existence of "open" IdPs within eduGAIN.

Google is easier. You just need to hook your SP to one IdP.

Mikael

>-peter


--- End Message ---

--- Begin Message ---

• From: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Tue, 12 Nov 2013 10:46:05 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: SWITCH

Regarding the question of self-registration IdPs:

> The whole concept of federation crucially depends on IdPs not
> willfully (or carelessly) asserting bogus data.
> As such, if there were in fact such an IdP as *ficticiously* described
> above (one that issued ePSA values for self-registered accounts
> without any checking), that would indeed do us all (including
> federations outside eduGAIN) a big disservice, IMO.
>
> Note that I don't know whether the unnamed "open" IdP in question
> actually issues entitlements or affiliations that way.

The one instance of a self-registration IdP that started this discussion
is now no longer in eduGAIN metadata. So, nothing to worry about anymore
in this matter.

Also, as far as I know, that IdP *did not* set any affiliation at all
for its users. Only name, mail, ePPN, ePTID, preferredLanguage.
Therefore, it was neither lying nor asserting bogus data.

-------------------------------------------------------------------------

Regarding the Test IdP discussion:
If I can see one common denominator in the discussion, it is probably
the one that it might be beneficial to hide certain IdPs by flagging
them somehow.


On 08.11.13 16:09, Rhys Smith wrote:
> The preprod and dev infrastructures are flagged to be hidden from
> discovery services, and the login pages on both are intentionally
> made to look nothing like the “proper” one.

@Rhys: How do you flag and hide the IdPs fro the Discovery Service?
Could you elaborate a bit more on this?


Best Regards
Lukas

--
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT GN3plus Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch


--- End Message ---

--- Begin Message ---

• From: Brook Schofield <schofield AT terena.org>
• To: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• Cc: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Tue, 12 Nov 2013 13:14:35 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

On 12 November 2013 10:46, Lukas Hämmerle <lukas.haemmerle AT switch.ch> wrote:

Regarding the Test IdP discussion:
If I can see one common denominator in the discussion, it is probably
the one that it might be beneficial to hide certain IdPs by flagging
them somehow.

On 08.11.13 16:09, Rhys Smith wrote:
> The preprod and dev infrastructures are flagged to be hidden from
> discovery services, and the login pages on both are intentionally
> made to look nothing like the “proper” one.

@Rhys: How do you flag and hide the IdPs fro the Discovery Service?
Could you elaborate a bit more on this?

See <wayf:HideFromWAYF/> in the UKFederation metadata.

Referenced in the document http://www.ukfederation.org.uk/library/uploads/Documents/federation-technical-specifications.pdf available (p.16) from http://www.ukfederation.org.uk/content/Documents/FedDocs

-Brook
--

===================================================
Brook Schofield, TERENA Project Development Officer
TERENA Secretariat, Singel 468 D, 1017 AW Amsterdam, The Netherlands
Tel +31 20 530 4488    Fax +31 20 530 4499    Mob +31 65 155 3991
www.terena.org

--- End Message ---

--- Begin Message ---

• From: Rhys Smith <Smith AT cardiff.ac.uk>
• To: Brook Schofield <schofield AT terena.org>
• Cc: "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Tue, 12 Nov 2013 17:29:26 +0000
• Accept-language: en-GB, en-US
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

On 12 Nov 2013, at 04:14, Brook Schofield <schofield AT terena.org> wrote:

> @Rhys: How do you flag and hide the IdPs fro the Discovery Service?
> Could you elaborate a bit more on this?
>
>
> See <wayf:HideFromWAYF/> in the UKFederation metadata.
>
> Referenced in the document
> http://www.ukfederation.org.uk/library/uploads/Documents/federation-technical-specifications.pdf
> available (p.16)
> fromhttp://www.ukfederation.org.uk/content/Documents/FedDocs

What he said :-).

Though if we were going to do something similar for eduGAIN now, it would be
much more sensible to do it “properly” - i.e. define an entity
attribute/category that indicates an entity is a test entity and/or an entity
attribute/category that indicates an entity desires to be less discoverable.

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith AT cardiff.ac.uk / rhys.smith AT ja.net
GPG: 0xDE2F024C

--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: "Rhys Smith" <Smith AT cardiff.ac.uk>, "Brook Schofield" <schofield AT terena.org>
• Cc: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 13 Nov 2013 11:36:20 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: Srce

I fully support Rhys saying:

if we were going to do something similar for eduGAIN now,
it would be much more sensible to do it “properly”

Miro

----- Original Message ----- From: "Rhys Smith" <Smith AT cardiff.ac.uk>
To: "Brook Schofield" <schofield AT terena.org>
Cc: <edugain-tsg AT geant.net>
Sent: Tuesday, November 12, 2013 6:29 PM
Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN


On 12 Nov 2013, at 04:14, Brook Schofield <schofield AT terena.org> wrote:

@Rhys: How do you flag and hide the IdPs fro the Discovery Service?
Could you elaborate a bit more on this?


See <wayf:HideFromWAYF/> in the UKFederation metadata.

Referenced in the document http://www.ukfederation.org.uk/library/uploads/Documents/federation-technical-specifications.pdf available (p.16) fromhttp://www.ukfederation.org.uk/content/Documents/FedDocs

What he said :-).

Though if we were going to do something similar for eduGAIN now, it would be much more sensible to do it “properly” - i.e. define an entity attribute/category that indicates an entity is a test entity and/or an entity attribute/category that indicates an entity desires to be less discoverable.

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith AT cardiff.ac.uk / rhys.smith AT ja.net
GPG: 0xDE2F024C



--- End Message ---

--- Begin Message ---

• From: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 13 Nov 2013 16:00:30 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: SWITCH

On 13.11.13 11:36, Miroslav Milinovic wrote:
> I fully support Rhys saying:
>
>> if we were going to do something similar for eduGAIN now,
>> it would be much more sensible to do it “properly”

+1


--
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT GN3plus Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-SG] [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 29 Nov 2013 10:22:58 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

* Lukas Hämmerle <lukas.haemmerle AT switch.ch> [2013-11-13 16:02]:
> On 13.11.13 11:36, Miroslav Milinovic wrote:
> > I fully support Rhys saying:
> >
> >> if we were going to do something similar for eduGAIN now,
> >> it would be much more sensible to do it “properly”
>
> +1

Given that there has been much support expressed for that idea here's
a first take on that:
https://refeds.terena.org/index.php/Entity_Category_LessDisco

Feel free to change it (or suggest change on the Talk/discussion page)
if that's not "done properly" yet.
Comments welcome, but not on this list (which should be more for
official business such as voting for PIONIER.Id -- hint, hint -- I've
been told).
So please comment on the REFEDS list as it's really not eduGAIN
specific even if eduGAIN would profit from it. Or email me personally.
-peter

Attachment: smime.p7s
Description: S/MIME cryptographic signature

--- End Message ---

--- Begin Message ---

• From: Rhys Smith <Smith AT cardiff.ac.uk>
• To: Mikael Linden <Mikael.Linden AT csc.fi>
• Cc: Peter Schober <peter.schober AT univie.ac.at>, "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Mon, 11 Nov 2013 17:56:56 +0000
• Accept-language: en-GB, en-US

On 11 Nov 2013, at 06:01, Mikael Linden <Mikael.Linden AT csc.fi> wrote:

> I still hope the issue of test entities and self-asserted attributes is
> going to be solved by a LoA specification.

Just let me reiterate a point here. Please do not conflate test/dev entities
with entities that allow self registration of users. They are two different
problems. The former is likely to exist for a specific purpose and either be
locked down tightly by the operators of that IdP, or connect to the same
identity store as the production IdP. The latter is likely to be a service
created for the purpose of self registering users, and will typically be very
open.

However, either way, as long as the entity has signed up to a particular
federation’s policies, and it asserts information correctly (e.g. only
asserting relevant scopes) then it’s an IdP just like any other.

If an IdP is “lying”, then that’s another problem entirely - and a problem to
be dealt with according to the home federation’s policies about entities that
wilfully assert inaccurate information (hang them at dawn).

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith AT cardiff.ac.uk / rhys.smith AT ja.net
GPG: 0xDE2F024C
--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: Lukas Hämmerle <lukas.haemmerle AT switch.ch>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 11:08:49 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: Srce

Lucas, all!

Test IdPs are more controversial because:

* They show up in Discovery Service unless extra measures are taken to
hide them (usability issue)
* They make a bad impression on people first looking at "what is in
eduGAIN") (reputation issue)
* They could potentially allow users accessing services with dummy
identities with too many/wrong attributes (security issue)

I fully support your arguments, and would like to add some more.

What if a user has both test and productional identity? He can than access the same service with both? IMO this can cause some additional work on the SP side (that should distinguish between test and productional identity).

FWIW in our federation we run separate test infrastructure for IdPs and SPs. So, they're either test or production, but cannot be both at the same time.

Miro


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 13:52:19 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

* Miroslav Milinovic <miro AT srce.hr> [2013-11-08 11:12]:
> What if a user has both test and productional identity? He can than
> access the same service with both? IMO this can cause some
> additional work on the SP side (that should distinguish between test
> and productional identity).

Depending on that what means, specifically, not even affiliation
checking or LoA would help there, I suspect: My real world identity
could still be fully vetted even if I used a "test identity" to log
in. But then the question is what are you trying to protect yourself
from, in the case of vetted, authorized subjects using "test"
identities?
Asserting an affiliation the subject does not have (one possible
interpretation of "test identity") to an (inter-)federated production
service is lying. That has nothing to do with "test IdPs" or "open
dPs", though.
-peter


--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: "Peter Schober" <peter.schober AT univie.ac.at>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 14:21:28 +0100
• Organization: Srce

Peter,

What if a user has both test and productional identity? He can than
access the same service with both? IMO this can cause some
additional work on the SP side (that should distinguish between test
and productional identity).

Depending on that what means, specifically, not even affiliation
checking or LoA would help there, I suspect: My real world identity
could still be fully vetted even if I used a "test identity" to log
in. But then the question is what are you trying to protect yourself
from, in the case of vetted, authorized subjects using "test"
identities?

I see possible confusion (both for user and SP).

If one user has, at certain point in time, several valid ids (one from productional instance of IdP, the other from test instance of the same IdP) this is IMHO cunfusing for her/him. The user has the choice to use either and can even unintentionally use both.
SP then has to enable user with id linking or switching feature. Are all SPs these day happy with this taks?

I understand that one can have several ids from different IdPs (with different LoAs) but with adding both test and production version of the same IdP to the eduGAIN metadata feed I fear that we make things complex without clear reason.

If those test IdPs can be easily separated from the productional ones, than fine. But for what reason then they are in the eduGAIN feed? "Normal" SPs will just filter test IdPs out. Even some test SPs will do so (becouse SP wants to test with real data).

BTW - are we talking about one test IdP per federation or about one test IdP per any IdP that wants to run its test instance with metadata in eduGAIN feed?

Miro


--- End Message ---

--- Begin Message ---

• From: Peter Schober <peter.schober AT univie.ac.at>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 15:15:01 +0100
• Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: ACOnet

* Miroslav Milinovic <miro AT srce.hr> [2013-11-08 14:24]:
> If one user has, at certain point in time, several valid ids (one
> from productional instance of IdP, the other from test instance of
> the same IdP) this is IMHO cunfusing for her/him. The user has the
> choice to use either and can even unintentionally use both.
> SP then has to enable user with id linking or switching feature. Are
> all SPs these day happy with this taks?

I don't see how this would ever happen. It last as an IdP admin of a
large academic institution (when I still was one) I would never let
any real "users" near /any/ test instance -- of /anything/. Out test
(and dev and whatever) servers and systems were all firewalled off so
access was only possible from management networks.

That still leaves potential Discovery confusion, as discussed.

(If others are in fact exposing their non-production services not only
to eduGAIN but to their users I would shake my head in amazement about
their user support capacities. From everything I've already argued
about successful authn not meaning much, no matter the IdP, I think
I'll continue asking why we'd need to prevent such entities from
showing up in metadata, though. I'm not personally fond of Metadata
censoring as a means of access control.

> I understand that one can have several ids from different IdPs (with
> different LoAs) but with adding both test and production version of
> the same IdP to the eduGAIN metadata feed I fear that we make things
> complex without clear reason.

If there are no clear reasons (something to be dealt with between the
home federation and the entity, I feel) then yes. If we just don't
know the reasons I'd rather deal with the discovery uglyness
seperately.
One can (and probably should) always ask the registrationAuthority in
such cases, IMO.

> BTW - are we talking about one test IdP per federation or about one
> test IdP per any IdP that wants to run its test instance with
> metadata in eduGAIN feed?

I think this is about more than one IdP per institution (of which more
than zero are not production entities in some sense).
I don't see why Federations offering test IdPs in their local
federation would need to expose such entities to eduGAIN but as far as
forbidding it, see above (don't assume anything from just authN).
-peter


--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: "Peter Schober" <peter.schober AT univie.ac.at>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 15:59:53 +0100
• Organization: Srce

Peter,

(If others are in fact exposing their non-production services not only
to eduGAIN but to their users I would shake my head in amazement about
their user support capacities. From everything I've already argued
about successful authn not meaning much, no matter the IdP, I think
I'll continue asking why we'd need to prevent such entities from
showing up in metadata, though. I'm not personally fond of Metadata
censoring as a means of access control.

I was only pointing to the complexity we are adding to the metadata.

I think this is about more than one IdP per institution (of which more
than zero are not production entities in some sense).
I don't see why Federations offering test IdPs in their local
federation would need to expose such entities to eduGAIN but as far as
forbidding it, see above (don't assume anything from just authN).

Again. No assumptions made. Just recognising additional work for all.

Miro


--- End Message ---

--- Begin Message ---

• From: Rhys Smith <Smith AT cardiff.ac.uk>
• To: Peter Schober <peter.schober AT univie.ac.at>
• Cc: "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Fri, 8 Nov 2013 15:09:33 +0000
• Accept-language: en-GB, en-US

On 8 Nov 2013, at 06:15, Peter Schober <peter.schober AT univie.ac.at> wrote:

> * Miroslav Milinovic <miro AT srce.hr> [2013-11-08 14:24]:
>> If one user has, at certain point in time, several valid ids (one
>> from productional instance of IdP, the other from test instance of
>> the same IdP) this is IMHO cunfusing for her/him. The user has the
>> choice to use either and can even unintentionally use both.
>> SP then has to enable user with id linking or switching feature. Are
>> all SPs these day happy with this taks?
>
> I don't see how this would ever happen. It last as an IdP admin of a
> large academic institution (when I still was one) I would never let
> any real "users" near /any/ test instance -- of /anything/. Out test
> (and dev and whatever) servers and systems were all firewalled off so
> access was only possible from management networks.

Let me put my Cardiff hat back on, and say that In ~7 years (blimey) of
running the IdPs for Cardiff, with a user population of ~ 35,000, and having
had prodn, preprodn, and dev (and a simpleSAMLphp dev IdP as well) IdPs for
that whole time, I’ve *never* had to deal with any user having problems
because of using both by accident.

The preprod and dev infrastructures are flagged to be hidden from discovery
services, and the login pages on both are intentionally made to look nothing
like the “proper” one.

So, not saying this is never going to happen, just that if done properly,
it’s not something to worry about. And even more importantly - it’s something
for the user organisation to worry about, or possibly the home federation,
but definitely not eduGAIN.


>> I understand that one can have several ids from different IdPs (with
>> different LoAs) but with adding both test and production version of
>> the same IdP to the eduGAIN metadata feed I fear that we make things
>> complex without clear reason.

It’s eduGAIN’s job to ship metadata between federations, not to worry about
the user. That’s a job for the federations that eduGAIN serves, or the end
user organisations themselves. If you start going down this route, are we
also going to start mandating how IdP’s login pages should look, so that
they’re not confusing to the user? Whether two organisations with similar
names aren’t both allowed to be a part of eduGAIN in case it confuses the
user? Etcetc.


> I think this is about more than one IdP per institution (of which more
> than zero are not production entities in some sense).
> I don't see why Federations offering test IdPs in their local
> federation would need to expose such entities to eduGAIN but as far as
> forbidding it, see above (don't assume anything from just authN).

Agree, that’s a different case entirely, but as you say, presence in metadata
does not mean *anything* other than the entity is present in metadata.

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith AT cardiff.ac.uk / rhys.smith AT ja.net
GPG: 0xDE2F024C

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

--- End Message ---

--- Begin Message ---

• From: Rhys Smith <Smith AT cardiff.ac.uk>
• To: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
• Cc: "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 6 Nov 2013 16:27:43 +0000
• Accept-language: en-GB, en-US
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

On 6 Nov 2013, at 08:00, Lukas Hämmerle <lukas.haemmerle AT switch.ch> wrote:

> Hello all
>
> Looking at the Identity Providers listed in the production eduGAIN
> metadata (mds.edugain.org), I noticed a few aspects that I think are
> worth discussing:
>
> * There are several IdPs with "test", "preprod", "beta" in their display
> names. It could be that just the names of these IdPs are not up-to-date
> but at least in one case, there are even two IdPs listed for the same
> organisation (one "test" and one "pre-pod”).

Speaking as an operator of three IdPs for a University in the UK
(prod/preprod/dev), there are good reasons for wanting them to be in eduGAIN
- so things can be tested without affecting end users of the production
systems.


> * There currently is at least one Identity Provider in eduGAIN that
> allows any user with a valid email address to create an account.
>
>
> My questions therefore are:
>
> * Do you think it is ok to have test/prepod/beta IdPs in eduGAIN?
> Is this a problem?

Speaking with my Janet hat on - one question back for you - how do you think
that eduGAIN (or the original registrar) would be able to tell if the entity
is a test/dev/preprod/beta entity in any easy and meaningful way, apart from
taking a guess based on what the entity’s owner happens to put in the DNS
name / entityId?

My feeling is that you would probably be able to tell in most cases due to
this naming, but not always.

If you put policy in place that these types of entities cannot be in eduGAIN,
then you really should need a better of way of identifying them, otherwise
you wouldn’t be applying the policy consistently. And a better way of
identifying them might require a shedload of work from fedops in categorising
all of their existing entities.


> - If so, should there be a rules/recommendation for federation
> operators on this subject?

You might have guessed my feeling here is no. If a federation operator has
registered an IdP for an organisation, and that organisation has agreed to
all of the usual T&Cs to have that entity registered, then it’s just another
entity with a SAML identity provider role, and is functionally no different
from a “production” IdP.

Rhys.

--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith AT cardiff.ac.uk / rhys.smith AT ja.net
GPG: 0xDE2F024C

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

--- End Message ---

--- Begin Message ---

• From: Olivier Salaün <olivier.salaun AT renater.fr>
• To: edugain-tsg AT geant.net
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 13 Nov 2013 16:13:45 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

Hello,

I'm going back to the beginning of this thread.
The guest IdP that Lukas mentioned is the one operated by RENATER. Back in April 2013 we added this IdP to eduGAIN to get rid of some bilateral configurations with SPs from the Terena/Geant community.

Now that I removed our guest IdP from eduGAIN, I realize that I broke authenticated access for eduroam admins to CAT <https://cat.eduroam.org/>. I'd like to provide an alternative to Facebook/Google/Linkedin/Twitter login for our eduroam admins; therefore I have to set up a bilateral configuration with CAT again.

Is this the way to go?

Le 06/11/13 17:00, Lukas Hämmerle a écrit :

Hello all

Looking at the Identity Providers listed in the production eduGAIN
metadata (mds.edugain.org), I noticed a few aspects that I think are
worth discussing:

* There are several IdPs with "test", "preprod", "beta" in their display
names. It could be that just the names of these IdPs are not up-to-date
but at least in one case, there are even two IdPs listed for the same
organisation (one "test" and one "pre-pod").

* There currently is at least one Identity Provider in eduGAIN that
allows any user with a valid email address to create an account.


My questions therefore are:

* Do you think it is ok to have test/prepod/beta IdPs in eduGAIN?
  Is this a problem?
  - If so, should there be a rules/recommendation for federation
    operators on this subject?

* Do you think it is ok to have Identity Providers in eduGAIN that
  allow any users with a valid email address to create an account?
  - What if these IdPs allow only creating accounts if the user
    has an email address from a known university/research
    institution in a particular country?
  - What if the accounts are created for example by the administrators
    of an (academic) research project?



Best Regards
Lukas

--

Olivier Salaün GIP RENATER Services Applicatifs aux Utilisateurs (SAU) Tél : +33 2 23 23 71 27 ou 06 73 29 40 52

http://www.renater.fr

--- End Message ---

--- Begin Message ---

• From: Chris Phillips <Chris.Phillips AT canarie.ca>
• To: Olivier Salaün <olivier.salaun AT renater.fr>, "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 13 Nov 2013 10:35:43 -0500
• Accept-language: en-US
• Acceptlanguage: en-US
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>

I have the same problem in Canada as well and am interested in the outcome.

We have a few IdPs in eduGAIN, but not everyone operates a SAML IdP (working on helping change that).

We have not pushed our Guest IdP to eduGAIN and don't intend to but would like to avoid the social ID providers.

I have not asked for a bi-lateral trust yet either, but it doesn't feel quite right given that we can use eduGAIN.

It would be an interesting question about whether or not a SocialID provider would be permissible in eduGAIN too (thinking of inCommon SocialID2SAML gateway).

Chris.

From: Olivier Salaün <olivier.salaun AT renater.fr>
Date: Wednesday, 13 November, 2013 10:13 AM
To: "edugain-tsg AT geant.net" <edugain-tsg AT geant.net>
Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN

Hello,

I'm going back to the beginning of this thread.
The guest IdP that Lukas mentioned is the one operated by RENATER. Back in April 2013 we added this IdP to eduGAIN to get rid of some bilateral configurations with SPs from the Terena/Geant community.

Now that I removed our guest IdP from eduGAIN, I realize that I broke authenticated access for eduroam admins to CAT <https://cat.eduroam.org/>. I'd like to provide an alternative to Facebook/Google/Linkedin/Twitter login for our eduroam admins; therefore I have to set up a bilateral configuration with CAT again.

Is this the way to go?

Le 06/11/13 17:00, Lukas Hämmerle a écrit :

Hello all

Looking at the Identity Providers listed in the production eduGAIN
metadata (mds.edugain.org), I noticed a few aspects that I think are
worth discussing:

* There are several IdPs with "test", "preprod", "beta" in their display
names. It could be that just the names of these IdPs are not up-to-date
but at least in one case, there are even two IdPs listed for the same
organisation (one "test" and one "pre-pod").

* There currently is at least one Identity Provider in eduGAIN that
allows any user with a valid email address to create an account.


My questions therefore are:

* Do you think it is ok to have test/prepod/beta IdPs in eduGAIN?
  Is this a problem?
  - If so, should there be a rules/recommendation for federation
    operators on this subject?

* Do you think it is ok to have Identity Providers in eduGAIN that
  allow any users with a valid email address to create an account?
  - What if these IdPs allow only creating accounts if the user
    has an email address from a known university/research
    institution in a particular country?
  - What if the accounts are created for example by the administrators
    of an (academic) research project?



Best Regards
Lukas

--

Olivier Salaün GIP RENATER Services Applicatifs aux Utilisateurs (SAU) Tél : +33 2 23 23 71 27 ou 06 73 29 40 52

http://www.renater.fr

--- End Message ---

--- Begin Message ---

• From: "Miroslav Milinovic" <miro AT srce.hr>
• To: Olivier Salaün <olivier.salaun AT renater.fr>, <edugain-tsg AT geant.net>
• Subject: Re: [eduGAIN-TSG] Test and Guest Identity Providers in eduGAIN
• Date: Wed, 13 Nov 2013 16:45:06 +0100
• List-archive: <https://mail.geant.net/mailman/private/edugain-tsg/>
• List-id: <edugain-tsg.geant.net>
• Organization: Srce

Olivier,

Now that I removed our guest IdP from eduGAIN, I realize that I broke
authenticated access for eduroam admins to CAT
<https://cat.eduroam.org/>. I'd like to provide an alternative to
Facebook/Google/Linkedin/Twitter login for our eduroam admins; therefore
I have to set up a bilateral configuration with CAT again.

this might be off-topics but let me answer:

CAT is behind the SP proxy named "eduroam supporting services" (listed in eduGAIN metedata) which also allows login via social networks so there is no special work for you as federation admin when it comes to configuration.

Nevertheless I think you should reinvite your admins to CAT (due to the fact that their e-ids have changed). For futher assistance please use CAT mailing lists and monitor AT eduroam.org for problems with AA process.

Regards

Miro



--- End Message ---