How Academic Institutions Can Become Collaboration-Ready and Make Federation Work Better
Federations like InCommon are there to help make collaboration happen for researchers, scholars, students, and staff. A very substantial analysis of how that’s going has just been published. It provides clear, practical, and very doable guidance on how academic institutions can make it work better.
Over the last 18 months an international group of people affiliated with a variety of research communities, large scale research e-infrastructures (or cyber-infrastructures), research and education (R&E) federations, and related organizations, organized themselves to assess the ways in which federation supports research.
The group gathered data describing how federation is used to enable the work of more than twenty different research communities, discerned numerous requirements commonly needed to operationalize and optimize the benefit of federated access to those research communities, analyzed these common requirements, and synthesized a number of recommendations aimed to improve the overall global federated access management ecosystem.
Their work has been published in a paper called “Federated Identity Management for Research Collaborations, version 2.0" (FIM4R v2), updating the original such effort of six years earlier. It’s a good read that pays a dividend on the time invested to ingest it (caveat: as one of the many authors, I am biased).
Several of the recommendations specifically address how academic institutions’ Identity Providers (IdPs) should be operated to better enable their users to federate with collaborative activities common across research and most academic disciplines. Paraphrasing a bit, key recommendations for academic institutions are:
- Release a limited set of attributes in accord with the Research & Scholarship Entity Category
- Include usability essentials such as logos and error URLs in the IdP’s federation metadata
- Participate in SIRTFI, a lightweight security incident response framework
- If you have people to whom you provide strong authentication credentials, such as those who work with sensitive research data or instruments, use the REFEDS MFA profile to extend that protection to federated services.
What each of these are and why they’re important is explained further below, together with how to do them. Some readers may recall a blog from November 2017 motivated by the National Science Foundation’s CC* program solicitation, which specifically required proposing campuses to address a similar list of needs. Some of that material is repeated here so that readers have a complete set of advisories in one place.
But before jumping into the What, Why, and How of the FIM4R v2 recommendations for academic institutions, let’s look at the Why Bother.
It turns out that researchers, scholars, and their needs for simple and secure online collaboration are everywhere. User data was collected from six US-based research projects in late 2017 as part of the work of the Attributes for Collaboration and Federation Working Group, jointly sponsored by InCommon’s Steering Committee, Technical Advisory Committee, and Community Trust and Assurance Board. The data showed that 81% of InCommon IdPs were home to at least one user of those six research projects.
That’s just six out of hundreds of similar projects in STEM areas, and almost every academic discipline likewise relies heavily on community-wide collaboration. Basically, the data show the unsurprising fact that effectively all academic institutions participating in InCommon have many faculty and students who collaborate with colleagues elsewhere in large and small activities. What is surprising is how few of these campuses use their InCommon participation to help them. Perhaps they just don’t realize that they could; if so, I hope this blog might help.
Most IdPs can be operated in a manner that greatly helps collaboration happen, and at most campuses doing so is easier than most other tasks central IT undertakes. Here’s how.
Participate in the Research & Scholarship Program
What and Why
Many federated academic services require a few user attributes to successfully complete login, usually name, email, and a persistent user identifier (called the “R&S attribute bundle”). An international program called the Research & Scholarship Entity Category (R&S) was established to meet this need. This program enables federated services serving a research or scholarly purpose to request that their national R&E federation (as InCommon is for the US) “tag” them with the R&S entity category. It also specifies how R&E federation operators vet such requests to ensure that such tags are only applied to appropriate services.
The R&S program further provides a means by which an academic IdP can automatically release the R&S attribute bundle when users login to services that have been tagged R&S, and a corresponding R&S tag to be given to an IdP to signal that it participates in this global program. This is important because some R&S tagged services will only permit a login to proceed if the user’s IdP is also tagged R&S.
It’s worth noting that releasing R&S attributes under the R&S program contributes to good privacy practice under the European General Data Protection Regulation (GDPR). REFEDS, the international organization of Research and Education Federations, conducted a thorough analysis of how attribute release under the R&S Category addresses GDPR requirements to arrive at this conclusion.
Check to see if your IdP is listed as already meeting the “REFEDS R&S Entity Category specification” by being displayed as “research-and-scholarship” on a green background. Those shown a red background are a legacy from before there was global agreement on the R&S Entity Category. Their R&S attributes are limited to InCommon services only, hindering user access to international R&S services.
A wiki page describes how to enable an IdP to automatically provide the R&S attribute bundle to R&S tagged services. Once you have done so, email firstname.lastname@example.org to request that your IdP be tagged as REFEDS R&S.
Include Usability Essentials in the IdP’s Federation Metadata
What and Why
When performing a federated login, logos help users quickly find their home organization to login from, and logos graphically reinforce which federated service they are accessing. An error URL is a landing page at the user’s home organization to which users are brought when there’s a technical problem with a federated login, so they aren’t left at a dead end.
Each month InCommon emails a “metadata health check” to campus IT people who are InCommon Site Administrators to notify of any IdPs or SPs that need attention. The criteria checked include presence of logo and error URL. A Site Administrator should login to InCommon’s Federation Manager and make the changes as advised. And they don’t need to wait for that monthly email - they can login in to the Federation Manager at any time and ensure that this information is present.
Participate in SIRTFI
What and Why
User accounts are potential points of compromise, and that extends to federated access. Since federation is used to protect vast amounts of data, expensive and unique scientific equipment, high performance computing equipment, and other intellectual property, researchers, their funders, and those who rely on their conclusions have a deep concern for the integrity of that data and equipment. SIRTFI is an international standard that describes a low bar of operational security practices that should apply to IdPs and SPs and establishes how to signify willingness to join the collaborative response to a federated security incident should it involve your IdP or SP. Adherence to SIRTFI also is good evidence of meeting the Baseline Expectation of “Generally-accepted security practices are applied to the IdP or SP”.
Complete a self assessment of your organization’s security practices to determine if they align with SIRTFI. If you agree with each normative statement included in the framework, you are SIRTFI compliant. To assert this compliance, use InCommon’s Federation Manager to so indicate.
Extend Your MFA/2FA Protections to Federation
What and Why
Where SIRTFI helps to manage a security incident, strong authentication helps avoid having one in the first place. The REFEDS MFA Profile is an internationally standardized means by which an SP that desires MFA (Multi-Factor Authentication) protection can signal that to an IdP, and the IdP can respond accordingly. Hence, if a user has MFA or 2FA, its protection is extended to a requesting SP.
For the Shibboleth v3.3.x IdP, add the following declaration to the authn/MFA section in general-authn.xml, and to any other relevant sections as appropriate, for example, the authn/Duo section if you use Duo’s 2FA.
<bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="https://refeds.org/profile/mfa" />
For other IdP technologies, please check the provider’s documentation.
Global research networks have become critical to science - they cannot be turned off. Likewise, global R&E federation has become critical to academic collaboration, including science - it cannot be turned off. Both of these foundational global infrastructures continuously evolve to become ever more valuable. The FIM4R v2 paper establishes a target for the next phase of evolution of global R&S federation. Academic institutions have their part, and the dividend that pays far exceeds the effort invested.