Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership


Chronological Thread 
  • From: Порхачев Василий <porhachev AT runnet.ru>
  • To: Peter Schober <peter.schober AT univie.ac.at>
  • Cc: Alan Buxey <alan.buxey AT myunidays.com>, Guy Halse <guy AT tenet.ac.za>, edugain-discuss AT lists.geant.org, "Ilya V. Vasiliev" <vasilyev AT runnet.ru>, Alexey Abramov <abramov AT runnet.ru>
  • Subject: Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership
  • Date: Fri, 16 Mar 2018 10:40:16 +0300

Hi, all
thank you again for taking care.

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

* Alan Buxey <alan.buxey AT myunidays.com> [2018-03-15 14:07]:
some federations already require SPs to sign their requests to IdPs
due to national law.

That's *not* the issue here -- IDPs should always sign and SPs only
risk opening themselfs up to trivial DoS attacks by signing, so sign
away!
The issue is with mandating that entities reject any unsigned
requests. *That* will make RUNNet IDPs non-interoperable with +90% of
known SAML SPs. (Wild guess, fee free to do the actual numbers.)

(I still doubt there's national law that prevents SAML WebSSO to be
used with relying on SAML 2.0 Metadata to verify requested ACS
endpoint URLs, but whatever. Not the issue here.)

That is our fault. 
Taking more precise view at http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf p.68
we think to rewrite this in accordance of standard.  



use eduPerson ones if they exist, use schac ones if they exist..if
neither exists, work to getting such created (in whatever space) but
don't just make ones up.

While I have not felt the need to do so myself there's nothing agains
making up your own local schema where you have unique local needs.
But you can't (should not, for specifics we'd have to dive into formal
attribute names vs. friendlyNames) make up your own attributes in
someone else's namespace, e.g. eduPersonWhateverNotInEduPerson.

* Guy Halse <guy AT tenet.ac.za> [2018-03-15 14:34]:
* It seems that a search was done for "Identity Federation" and
  RUNNetAAI inserted where it appeared. There are some places where
  this doesn't make sense, for example in the first paragraph of the
  Introduction where the broad concept of a federation is introduced.

Note that we've conciously written the federation policy template in a
way that you would only need to replace that in once place, defining
"the Federation" to mean your federation in the rest of the document.
(The comment above may apply to a different document, though, which
points at the diverse and scattered history of all those documents:
federation policy, technology profile/s, registration practice
statements, etc. It's not at all impossible we could move all of these
to a common editing schema, using consistent terminology, etc., but
knowing who is the most likely person to be tasked with such an effort
I guess we can agree that N. has more important things to do. :)

-peter

Kind Regards
Vassiliy Porkhachev


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





Archive powered by MHonArc 2.6.19.

Top of Page