By Mikkel Hald, 27/10/21
Researchers from countries participating in the LUMI consortium will, through eduGAIN, get access to the LUMI super computer using the digital identities they hold at their institutions. But only if these institutions have a required level of maturity in their digital identity management – and are able to state this in the login tokens they send for their users. This requirement is a result from the Puhuri project working group developing the AAI infrastructure around LUMI.
More specifically, each institution wanting to grant its researchers access to LUMI must have identity-proofed the users in question at level medium or high according to the REFEDS Assurance Framework (“RAF”), an international standard for securing digital identities at institutions for research and further education.
Another requirement is for the institution to never re-assign or re-use values of eduPersonPrincipalName. This is already expected of the institutions participating in WAYF as user organisations but is seen to be stressed by LUMI.
At the technical level, the institution must be able to signal its compliance by sending, for the user accounts in question, the corresponding values of the attribute eduPersonAssurance – which may well have more than a single value. In addition to the value 2 the institution must be able to send, among other values, the values https://refeds.org/assurance/IAP/medium and https://refeds.org/assurance/ID/eppn-unique-no-reassign. As of March 1st, 2023, access to LUMI will be blocked for institutional accounts not releasing the required values of eduPersonAssurance.
By logging onto this site with your institutional account you can test if your institution currently sends all the attribute values that will be required for LUMI access.
In the longer term, LUMI will probably also adopt a requirement of multi-factor authentication, likely corresponding to the REFEDS MFA Profile. But here and now, what matters is what you've done to make sure the user account was issued to the intended physical person.
Implementing RAF seemingly is becoming a requirement with still more research infrastructures and publishers internationally, and so, research institutions in Denmark and the North Atlantic initiating this without delay will be at an advantage. Strictly speaking, an institution must in fact conform to the conformance criteria of RAF (see its Section 3) to be able to truthfully send the eduPersonAssurance values required by LUMI.
LUMI's requirements for institutions' identity proofing of their users are also listed below on this page. Requirements not mentioned in this article are already met by WAYF member institutions by virtue of their WAYF membership. For instance, WAYF has, in its institutions' eduGAIN metadata, marked every institution as having approved in advance its users identifying vis-à-vis service providers in the Research & Scholarship entity category. Similarly, all attributes required by LUMI are also in place already – except, as indicated here, for eduPersonAssurance.
The current version of REFEDS Assurance Framework defines its assurance levels by referencing those of other frameworks – which consequently you must study to learn what implementing RAF's medium level requires more specifically. The clearest option perhaps is studying the “BIRCH” assurance level of the IGTF framework detailed here, and implementing that. RAF's own brief example of what could pass for a valid medium identity proofing is also worth reading. In addition, this slidedeck from American NIAID provides a rather good overview. Possibly, a MitID verification of an institutional account could equal an identity proofing to RAF's level high.
Finally, do bear in mind that implementing RAF's medium assurance level is only a strict requirement for those accounts actually in need of LUMI access – there is no need to do it for all accounts at the institution. One option, consequently, is to perform the vetting process for just the few users with a need for LUMI access, then mark their records in the user base with a code (or more codes) and program the institution's SAML identity provider to transform these into the required values of eduPersonAssurance.