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

[Порхачев Василий <porhachev AT runnet.ru>]

Dear Piter,

Thank you indeed for your comments. 

We see that it is a rather complicated task to get all the issues inline both with eduGAIN traditions and local laws.

We hope that will be ready with feedback in 1-2 days.

Kind Regards
Vassiliy Porkhachev

RUNNet, Saint Petersburg
skype pva-pva.1967
porhachev AT runnet.ru
office +78123317566#2219
cel +79817659337

14 марта 2018 г., в 22:53, Peter Schober <peter.schober AT univie.ac.at> написал(а):

* Brook Schofield <brook.schofield AT geant.org> [2018-03-13 19:00]:

their policy and MRPS is linked from their federation page
http://www.runnet.ru/en/services-en/runnetaai-en but for
completeness you can find them here:

Things I noticed from a first glance:

# ToS http://runnet.ru/images/docs/federation/Terms_of_Service_Agreement_EN.pdf

1.1 mentions "the Operator's website at http://www.aai.runnet.ru." but
that host doesn't resolve in DNS. (https://aai.runnet.ru/ does but is
not "the Operator's website", AFAICT).
3.1: Does that mean participants have to yearly re-sign and submit
this ToS Agreement (as each one expires after 12 months)?


# TP http://runnet.ru/images/docs/federation/RUNNetAAI_Technological_Profile_en.pdf

3.1: Personally I think it's a mistake to demand that:
 "All members of the Federation MUST take the efforts to update the
 software, including Web server software, databases and operating
 system, to the latest stable versions."
This would prevent anyone from using the packaged versions provided
and supported by common GNU/Linux distributions (Debian, Ubuntu,
CentOS, RHEL, etc.) within the federaton. If you simply mean that
members must run supported versions of the software that's just as
simple to state (I just did), though not easy to enforce.
Maybe look at what SIRTFI has to say on that matter.

3.4: "All messages in SAML format between entities MUST be signed."
I think requiring that is a mistake, too: There is no need to sign
authentication request. If you disagree please explain what kinds of
problems signing auth request should avoid.
If your IDPs followed your requirement "If the SAML message is not
signed [...] the message should be rejected by the receiving party"
they would not be to interoperate with almost all SPs in eduGAIN.
Very bad.

4.1 "The key responsibility of each Federation Member is to publish
the metadata of all entities run by the Member."
This could be read like a prohibition for a federation member to run
private (i.e., not exposed to the federation or eduGAIN) services. I
doubt that is what you want.

4.2/6.3: Not sure what this metadata URL business is about. There is
no technical requirement for a SAML entity to publish its own SAML
metadata. You should be publishing their metadata, and you'll probably
want to allow creating it from scratch (or from emails) in your
registry, i.e., not mandating a "URL" for entities' metadata.

5.1: "For the functioning of the Federation services, IdP MUST issue the
minimum set of attributes and SP MUST authorize End User or reject by
the following minimum set of attributes:"
It's against the spirit of identity federations to require the
transmission of data that's not needed by the service, so every
statement that mandates release of attributes to all serices is
problematic. YMMV, of course.
I disagree with the "minimum set of attributes", though:
* ePPN: Is on the way out. Too many concepts and desires forced into
 one attribute. For new deployments probably best avoid it.
 (Use Subject-ID or email instead.)
* eduPersonAffiliation and schacHomeOrganization: Replace both of
 these with just eduPersonScopedAffiliation. Has (more widely
 implemented) scope impersonation checking and needing only 1 is
 better than needing 2.

5.2: Many issues. Picking a few:
* "displayName: Name of organization/unit to display"
No, when sent as a SAML Attribute this will always be interpreted by
the SP as the name of the person logging in. (Units and Orgs do not
authenticate via SAML Web SSO, people do.)
* And avoid "cn", for the reasons given at the end of the "cn" section
in http://macedir.org/specs/eduperson/#cn
* Seems you're just copying stuff from the Internet2 website? I've
never seen a deployment of the eduOrg schema, so I very much doubt you
will need this, esp as SAML attributes sent with each login
(e.g. "eduOrgIdentityAuthNPolicyURI").
* No idea what "enEduOrg" should be. If it's your own invention I'd
suggest to not call it "enEduOrg", maybe "runnetEduOrg"?
* Also don't call your made-up attributes eduPersonSomething when
they're not in eduPerson (e.g. eduPersonBirthDate, eduPersonLegalName,
etc.). Instead use existing attributes where possible
(e.g. schacDateOfBirth) or create additional ones in your own
namespace.


# Form http://runnet.ru/images/docs/federation/RUNNetAAI_Application_Form_-en.pdf

Are you limiting applications to Russion orgnisations? Otherwise are
you prepared to hanve requests that have no idea what e.g. 6 "OGRN"
means? Or where the "Tax ID" comes from another country (or none
exists)? E.g. I have no idea what an "Legal address index" is.


# MRPS http://runnet.ru/images/docs/federation/RUNNetAAI_MRPS_en.pdf
4: You define your registrationAuthority there to be:
"http://runnet.ru/en/services-en/runnetaai-en".
(I'd recommend shortening this to just "http://runnet.ru" as that's
just as unique and less likely to become a broken URL going forward.)
I note that in the metadata you publish the only IDP has a
registrationAuthority of "urn:mace:runnet.ru", though, one SP has a
registrationAuthority of "http://www.runnet.ru/en/" and the other SP
has none.
So likely those 3 registrationAuthority values should be identical
everywhere.
(Also remember that the mdrpi:RegistrationPolicy value MUST change if
you ever update your MRPS, which is why the example in the template
has an example URL with a date.)

5.1: There's an old bug in the MRPS
(cf. https://www.terena.org/mail-archives/refeds/pdfrCrj5FVNsj.pdf),
which now is part of your document, too:
"A member’s canonical name matches registrant information shown in DNS."
So that should probably be "WHOIS", not "DNS". Not sure how useful
WHOIS will be, going forward, and how exact you'd want those matches
to be.

6.1: That section negates the fact that you're running the Jagger
registry software. Making changes there (using the guidance provided
by the UI) seems much more sensibel and less error prone than
insisting on email change requests?


# Metadata

As for your SAML 2.0 Metadata: That also contains non-sensical/invalid
RequestedAttribute elements such as
 <md:RequestedAttribute FriendlyName="transientId" Name="urn:oid:1.2.3.4.5.6.7.8.9.10">
but I think that's actually the fault of the Jagger software, IIRC.
(There's no need to ever request transient Name IDs, but if you really
needed to, you would not use RequestedAttribute, as transient NameIDs
are not SAML Attributes. Instead you'd use the NameIDFormat element in
SAML 2.0 Metadata.)


* Brook Schofield <brook.schofield AT geant.org> [2018-03-13 19:00]:

This application is from an organisation that is closely aligned
with the GÉANT community and their participation in eduGAIN will
further build links to RUNNet and the Russian Academic community.

Would anyone care to spend just a few words on the [lack of]
relationship with фEDUrus who have sigend the eduGAIN policy almost 5
years ago and already have registered 14 SPs and 9 IDPs?
The more the merrier, of course, but can we at least assume that tools
or more importantly knowledge (and maybe metadata) are being shared?

-peter