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

[Thilina Pathirana - LEARN <thilina AT learn.ac.lk>]

Hi Vlad and Peter,

My explanations inline,


On 3/15/19 4:10 PM, Peter Schober wrote:
> * Vladimir Mencl <vladimir.mencl AT reannz.co.nz> [2019-03-15 00:21]:
>>   * Joining is for NREN ("LEARN") members only
> Yeah, that doesn't work for Service Providers.
>
> It also may be a meaningless policy these days when interfederation
> via eduGAIN is the norm/default esp. for new federations: ALL of the
> entities you get via eduGAIN will NOT be members of our NREN, yet they
> are in the same "trust fabric". So what does this reall buy you?
> Strong local trust relations with (comparatively) few local IDPs mixed
> in with widely-varying-to-low/no trust relationships with thousands of
> entities (IDPs and SPs) coming in via eduGAIN?
>
> E.g. the UKfederation has no such restriction. Of course of you remove
> that requirement you need some other criterion on who you want in your
> federation. But why not simply state that the steering group (whatever
> that's called and whoever that is in your case) decides on
> eligibility? That keeps the path open to possibly add desirable IDPs
> that for some (e.g. political) reason cannot join the NREN. (Unless
> you're certain you want and will be able to force those to join the
> NREN, too. Otherwise they can just join /your/ federation by going to
> the UKfederation, I guess ;) in which case you haven't achieved
> anything with that requirement.)
>
Yes, we also were discussing how this should happen, and as suggested I
will revise the documents as " LEARN Management will decide the
eligibility for both IDP and SP's"
>> Technical:
>>   * metadata signing certificate is self-signed valid for 10 years - that
>> looks good.
> You can always rewrap the signing key, but when I last did this I used
> all the remaining time in the 32-bit signed UNIX epoch (2038):
> Either period is too long for a short-lived credential (which would
> shorten the window where something bad could happen) and so will need
> to be pulled hard in case anything bad actually happens. 10 or 20
> years doesn't really make any difference here, so I used 20.
>
> (Ironic that we started out with 10 years too, assuming we'll *long*
> have moved on to other technologies by then, which was not the case
> for us.)
Thanks Peter for your recommendation, I was planning to roll out a new
4K key and with suggestions added by Vlad and Farhan. Will update as
soon as I do the changes.
>>     * there is however a personal email address in the Subject+Issuer DN of
>> the certificate (thilina AT learn.ac.lk) - should have been an alias.  But
>> that's too late to change now.
> Not too late. Just rewrap the same key in a new cert with different
> data. The identity data of the cert doesn't affect signatures made
> from the key so neither signing nor signature validation should be
> affected by a rewrapped key in a different cert.
>
> -peter
>

On 3/15/19 4:50 AM, Vladimir Mencl wrote:
>
> Hi,
>
> I have started by reading the MRPS (... and comparing it with the
> REFEDS MRPS template along the way).
>
> Overall, the application looks good to me, but there are some points
> to be clarified - see below.
>
> * MRPS based on template without pretty much any changes (GOOD).
>
> * Section "3.Member Eligibility and Owners"
>   * Federation registration policy is at the link provided (GOOD)
>
>   * Joining is for NREN ("LEARN") members only
>   * Strong process - documents to be signed by head of institution,
> verification also at senior managerial level.  Uses LEARN member
> registry for name checking.
>
>   ISSUE: this is however clashing with the Federation Policy.  While
> it says Home Organisations can only be members of LEARN, Service
> Providers can be "Any party that provides a service that is
> recognizable as usable for R&E community".
>
>    The checks documented in this section then completely fails to
> apply - such Service Providers would not be found in the LEARN Member
> Registry.
>
>    I think this section should be expanded to also cover how such
> organisations would get checked.
>
>
> * Section "4. Metadata Format"
>    The example given should use registirationAuthority and
> RegistrationPolicy values specific for this federation - please provide.
Sorry for my mistake, I will correct that
> * Section "5. Entity Eligibility and Validation"
>    I see this section deviates from the MRPS template, dropping any
> mention of IdP scope - both the clause in 5.1, and the whole section
> "5.3 Scope Format".
>
>     Was there a particular reason for omitting scope from the MRPS?
I was following the guidelines from
https://wiki.refeds.org/download/attachments/1605645/MRPS-templatev1.pdf?version=2&modificationDate=1516014622994&api=v2
and I am not sure there were any dropped parts. Please advice more on this.
>
> * Section "6. Entity Management"
>    - might be contradictory: for entityChange requests, it states they
> should be emailed to noc AT learn.ac.lk, but the Join page points to
> Federation Registry, which appears to be self-service (but could not
> confirm, just making assumptions here).
>
>    Can you please clarify?
>
>    Also, when I tried the Federated Login link at the registry, it
> gave me an Internal Server Error.
I will change it as "Communication of change happens via email to
noc AT learn.ac.lk or via Federation tool", at the moment we haven't
correctly enabled federation access to jagger tool and that is the
reason for that. We thought adding it after enabling edugain.
>
> * Section "2.Introduction and Applicability"
>
> The URL to get latest published MRPS only points to landing page, not
> exact document ... and not that obvious where to find the document.
> Took me a while - only once I navigated through "Join" -> "Federation
> Registry", I found I can see the key documents from
> https://fr.ac.lk/ ... but this was not at all obvious.
>
I will correct those links by adding a new category in
https://liaf.ac.lk as "Policy"
>
> (I also found a link to the Federation Policy in References - that was
> helpful, thanks).
> IdentityFederationPolicy (v1.0):
> https://fr.ac.lk/templates/IdentityFederationPolicy-LIAFv1.0.pdf
>
>
> Technical:
>   * metadata signing certificate is self-signed valid for 10 years -
> that looks good.
>     * there is however a personal email address in the Subject+Issuer
> DN of the certificate (thilina AT learn.ac.lk) - should have been an
> alias.  But that's too late to change now.
>
>   * metadata signature, https endpoints, metadata schema are all good
>
>   * I see in the metadata, the EntitiesDescriptor Name element has value
>       "/opt/pyff/fed"
>     As per SAML 2.0 Metadata specification, it should be:
>        "A string name that identifies a group of SAML entities in the
> context of some deployment."
>
>     A string like "liaf.ac.lk" would allow referring to all entities
> in your metadata.  (In your internal use within LIAF - the name gets
> dropped once the metadata traverses through the eduGAIN aggregator).
> But pointing it out because I noticed it...
Thanks I will change it.
>
> * And if possible, please make links in the MRPS PDF clickable (had to
> select the link text and paste into a browser)
>
>
Hmm, I tested this with the firefox, safari and chrome and it seemed
working for me. Anyway I will make sure it works on the new revision,
>
> But overall, congratulations on a job well done.
>
> I might have gotten into more detail than needed - overall, the
> federation looks all good to me, just the points I noticed...
>
>
> Cheers,
> Vlad
>
>
> On 9/03/19 00:57, Brook Schofield wrote:
>> All,
>>
>> I present to you the application of Sri Lanka / LIAF who has signed
>> the eduGAIN Declaration, has a policy based on the policy template,
>> is self declaring their federation as a production service and is
>> wanting to join the global R&E federated environment.
>>
>> You can find more detailed information about the federation under
>> "eduGAIN Candidates” at
>> https://technical.edugain.org/status.php
>> which contains links to their policy and MRPS.
>>
>> This application is from an organisation that is closely aligned with
>> the GÉANT community via their participation in the Asi@Connect
>> project and has been receiving support via the BACKFIRE project and
>> TF-IAM activities within APAN to support their participation in eduGAIN.
>>
>> So I ask the following federations to specifically review the
>> submission by LIAF:
>>   * Malaysia / SIFULAN
>>   * Moldova / LEAF
>>   * Mozambique / CAFMoz
>>   * The Netherlands / SURFconext
>>   * New Zealand / Tuakiri
>>
>> All eduGAIN members can (and should) provide feedback on this but to
>> share the burden of review around, these five (5) federations have
>> a specific responsibility.
>>
>> If you have any questions please contact the LIAF team that are
>> subscribed to this mailing list as well as CC’d to this message.
>>
>> Formal components of the membership process will be via the eduGAIN
>> Steering Group mailing list.
>>
>> Brook Schofield
>> eduGAIN Steering Group Chair
>> GÉANT
>> M: +31651553991
>> Skype: brookschofield
>>
-- 
Thilina Pathirana
Network/Systems Engineer
Technical Assistance Center (TAC)
Lanka Education And Research Network (LEARN)
T: +94812003036 | M: +94770055755 | F: +94812385715
www.learn.ac.lk | www.thilinapathirana.xyz

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature