A Roadmap to be NIH Ready

The National Institutes of Health (NIH) is enhancing its Login Service→ gateway to streamline external user access to NIH online resources. Over time, the Login Service will protect access to a wide range of NIH resources such as PubMed, electronic Research Administration Portal, dbGaP, and many other centers of sensitive data. 

To do this, the NIH Login Service needs federated identity provider systems to implement the following:  

• Release Necessary User Information - Release the user information defined in the REFEDS Research & Scholarship (R&S) entity category. 
• Multi-factor Authentication - Implement multi-factor authentication (MFA) request and response signaling using the REFEDS MFA Profile and perform MFA for a user when requested by the NIH Login Service.
• Share identity assurance information - Signal user identity assurance information using the REFEDS Assurance Framework.

Time frames and other details about each of these are addressed in corresponding sections below. Some details will only become known (even to NIH) over the coming months. InCommon will update this page with that information as soon as it is known.

Release Necessary User Information 

What information do I release?

NIH requires  identity providers to release a standard set of basic, non-sensitive information (persistent unique identifier, name, email + affiliation) for users signing in to the NIH Login Service. 

How do I do it?

If your identity provider supports the REFEDS Research & Scholarship (R&S) Entity Category→, you already meet this requirement. 

If you do not yet support R&S, for best results, configure your identity provider to support the REFEDS Research & Scholarship (R&S) Entity Category. If you are unfamiliar with R&S, the R&S Explained in Plain English page provides a good introduction.

If you are unable to take the release-by-category approach, either for technical or policy reasons, you should configure your identity provider system to release the named user attributes to the NIH Login Service service provider (Entity ID: https://federation.nih.gov/FederationGateway) on a bilateral basis. 

When do I need to do this?

As soon as possible. NIH already requires these attributes. Please see the “What happens if we miss a deadline?” section below for further information.

Multi-factor Authentication (MFA)

What is NIH asking for?

Two things. First, NIH is asking your identity provider to recognize MFA authentication requests sent by the NIH Login Service using the syntax defined in the REFEDS MFA Profile. Whether your identity provider performs MFA or not, it also expects your identity provider to respond using the same profile. 

Second, users trying to login to NIH services that require MFA will need to actually be authenticated using a MFA technique consistent with the REFEDS MFA Profile. Further, the identity provider must respond to the NIH Login Service that MFA has happened (using the REFEDS MFA Profile).

How do I do it?

InCommon recommends that campuses proceed in two steps. First is to enable your identity provider system to implement the REFEDS MFA Profile. The REFEDS MFA Profile wiki→ is an excellent place to start on that task. If your identity provider system doesn’t enable support for this profile, a “plug-in” may be available to add that capability to it. See the Consulting Services section below.

The second step is to ensure that those of your users that need MFA for access to their NIH services have it. For campuses that have not yet implemented MFA broadly, institutions can use the NIH RePORT tool to identify researchers to communicate with: https://report.nih.gov/award/index.cfm.

When do I need to do this?

The Key Dates section below identifies NIH services with an MFA requirement and the date by which each service will enforce it. Users using campus credentials to login must have their use of MFA positively signaled to the NIH Login Service before the enforcement date.

InCommon recommends that campuses proceed as soon as possible to enable REFEDS MFA Profile support in their identity provider systems, and then proceed to determine whether all of the users who access NIH have been provided with MFA.

Share Identity Assurance Information

What is this?

Identity assurance is a measure of confidence that the person using a credential to login is the person to whom the credential was issued, and is in fact who they claim to be. NIH relies on the REFEDS Assurance Framework→ (RAF) for its definitions of several identity assurance values as well as the means for an identity provider to communicate the identity assurance information associated with the user logging in. RAF defines four such values: low, medium, high, and local-enterprise. The first three reflect increasing rigor of identity proofing and credential management processes used, while the fourth conveys that the institution is satisfied with the level of identity assurance for its own critical internal operations, which may give relying parties sufficient confidence for their own purposes.

What is NIH asking for?

The NIH Login Service will soon begin checking identity assurance information for researchers who access sensitive datasets and services. 

Not all NIH resources will require the highest level of identity assurance. Some will continue to require no identity assurance information, others will choose to accept less rigorous measures of identity assurance, and some may start by accepting those and eventually shift their requirements to more rigorous measures, giving campuses time to develop their ability to determine and communicate such identity assurance information about their users. 

InCommon recommends that you start the planning process and begin taking the first steps. 

How do I do it?

Start with the Basics

A first step in this process is to configure your identity provider to release the “local enterprise” value for users who meet the requirements. To find out how, visit the REFEDS Assurance Framework Implementation Guidance for the InCommon Federation→.

The local-enterprise identity assurance type is designed to convey that the credential belongs to a user you trust to sign into your own institution’s critical systems. Sharing this information should be an easier first step since institutions likely already maintain an accurate user list for these systems. Doing so does not depend upon a deep understanding of business processes and integration of IAM systems with business systems to capture identity proofing information.

HOWTO: Releasing assurance information via eduPersonAssurance

Plan and Grow

We recognize that implementing an identity assurance  program can be a complex endeavor requiring significant time and effort from multiple stakeholders in your institution. Becoming fully NIH ready may be a journey measured in years, not months. There is no immediate expectation that institutions will immediately meet the highest levels of identity assurance. In fact, different NIH resources will require a varying subset of these requirements. Right now, we are asking you to start the planning process and begin taking the first steps.

Using the REFEDS Assurance Framework Implementation Guidance for the InCommon Federation→ as support, iInstitutions should establish a task force consisting of stakeholders from IT and major person data stewards to develop strategy, identify funding, and devise implementation plan to communicate a user’s identity proofing levels using the values defined in the REFEDS Assurance Framework.

When do I need to do this?

Institution should begin the discovery and planning process as soon as possible so that it can budget, if needed, for full implementations in the 2022-23 fiscal year. However, plan to release the local-enterprise value for qualified users as soon as possible. 

What happens if we miss a deadline?

If you do not currently release required attributes to NIH services, people at your campus are currently using either login.gov credentials or some form of NIH-provided credentials to access their services. Likewise, if you don’t get MFA or identity assurance support in place before a deadline, your users will be forced to get a login.gov credential in order to proceed to access an NIH service having those requirements (NIH-provided credentials are being deprecated).

However, the NIH Login Service will soon provide a self-service means for such users to elect to use their campus credentials instead, provided that your campus identity provider system meets the requirements described on this page. So, if you miss a deadline, some of your users will be inconvenienced, but they’ll be able to return to using campus credentials once you finish implementation. Of course, it will be the user’s choice at that point which credentials they will continue to use.

The Key Dates section below will be updated with the date on which the NIH Login Service will implement this capability, once that is known.

Timeline, Community Activities, and Help

Timeline

Community Activities

Several InCommon and international working groups are working to develop additional materials to clarify additional implementation details. 

The Assured Access Working Group, chartered by the InCommon Trust and Assurance Board (CTAB), has developed the REFEDS Assurance Framework Implementation Guidance for InCommon Participants document to provide campus-level implementation guidance on implementing the REFEDS Assurance Framework by leveraging common campus identity proofing processes. 

The REFEDS MFA Subgroup, a taskforce chartered by the REFEDS Assurance Working Group→, is answering detailed questions around MFA transaction handling. 

Consulting Assistance

Partners participating in the InCommon Catalyst Program→ are skilled and ready to help you design and implement solutions to meet these NIH requirements. If you need help, these Catalysts are great resources:

• Cirrus Identity→
• Research Data and Communication Technologies (RDCT)→ 
• Spherical Cow Group→
• Unicon→

Key Dates (as they become known)

Details of specific deadlines and requirements are gathered here, as they become known to InCommon. Some of the following are placeholders that represent a subset of the information InCommon expects to learn in the coming months.

Electronic Research Administration Portal (eRA)

Effective September 15, 2021, eRA (https://era.nih.gov) will require all of its users to sign in with MFA. eRA will accept qualified federated credentials. To qualify, the IdP needs to authenticate the user using MFA and signals the outcome using REFEDS MFA Profile. In addition, eRA will require the IdP to release user attributes defined in the REFEDS R&S category.

About eRA

eRA is NIH’s research administration portal. Principal Investigators and grant administrators from universities and research organizations use eRA to apply for and manage NIH-funded grants. eRA has about 40,000 users and over 204,000 grants in its database. Over 130,000 of the grants are issued to InCommon participants. 

Impact

If your institution receives NIH funding, your research administrators and principal investigators likely have access to eRA. 

Users who cannot sign in using a qualified credential from their home institution will be directed by eRA to create and use a login.gov credential to sign into eRA.

IdP Operator: sign into the eRA Security Compliance Check Tool→ to determine if your IdP meets eRA requirements.

National Center for Biotechnology Information (NCBI; PubMed)

The National Center for Biotechnology Information (NCBI) operates PubMed, MyNCBI, SciENcv, MyBibliography, and a number of NCBI-managed data services. It will transition its services to use only federated credentials for user access ( https://ncbiinsights.ncbi.nlm.nih.gov/2021/01/05/important-changes-ncbi-accounts-2021/). 

NCBI requires a federated IdP to release attributes defined in R&S. It does not require MFA or identity assurance information. 

About NCBI and PubMed

The National Center for Biotechnology Information (NCBI) is a division of the National Library of Medicine (NLM) at the National Institutes of Health (NIH). As a national resource for molecular biology information, NCBI's mission is to develop new information technologies to aid in the understanding of fundamental molecular and genetic processes that control health and disease. 

PubMed is one of the world’s largest online biomedical research databases. It has millions of users around the world. It is likely that all universities have some students or faculty accessing PubMed today. 

dbGaP

About dbGaP

dbGaP→ is the database of Genotypes and Phenotypes (dbGaP) was developed to archive and distribute the data and results from studies that have investigated the interaction of genotype and phenotype in Humans.

All of Us

About All of Us

The All of Us Research Program→ is inviting one million people across the U.S. to help build one of the most diverse health databases in history. We welcome participants from all backgrounds. Researchers will use the data to learn how our biology, lifestyle, and environment affect health. This may one day help them find ways to treat and prevent disease.

NIMH Data Archive

About NIMH Data Archive

The National Institute of Mental Health Data Archive (NDA)→ makes available human subjects data collected from hundreds of research projects across many scientific domains. NDA provides infrastructure for sharing research data, tools, methods, and analyses enabling collaborative science and discovery. De-identified human subjects data, harmonized to a common standard, are available to qualified researchers.  Summary data are available to all.

NIH Login Service

About NIH Login Service

The NIH Login Solution is an NIH Identity and Access Management service offered by CIT to provide centralized authentication and Single Sign On (SSO) capability for web-based applications. The NIH Login is a "one-stop shop" which allows logins from all of NIH staff, eRA Commons, HHS employees, and various Federated partners. 

Researcher Authorization Service (RAS)

About RAS

RAS (https://datascience.nih.gov/researcher-auth-service-initiative) facilitates access to NIH’s open and controlled data assets and repositories in a consistent and user-friendly manner.