Authenticate users from other academic institutions

Last updated: November 15, 2023
Audience: IT Staff / Technical

This page is focused on extending UW Shibboleth beyond UW NetIDs and what’s required to implement. If you are looking to extend Entra ID beyond UW NetIDs, simply send an email-based guest invitation.

Want some help?
Are you exploring ways to provide services to people from other universities? Contact us to explore approaches to using federations to enable access across organizations.

Overview

About InCommon and eduGAIN
The InCommon Federation and eduGAIN help you authenticate users from other universities without having to sponsor UW NetIDs. These federations extend the scope of single sign-on from one organization to many organizations that trust each other. InCommon includes more than 500 universities in the U.S. that you can rely on for user authentication. eduGAIN increases the total to more than 3,000 organizations across 60 countries.

About Entra ID federation

Microsoft Entra IDhas multilateral federation within itself, automatically allowing you to authentication with more than 400 million users across 860K Entra ID tenants. Additionally, specific IdPs can be federated upon request.

How federations provide value
InCommon and eduGAIN help you in two ways. First, they verify the organizations that participate in the federations, collect their registration information, and then publish it centrally so that you and other participants can find it in a common, trusted, public location. Therefore, you only need to register a service once to participate with others in these federations. InCommon and eduGAIN also help develop and coordinate current best practices—both technical and administrative practices—so that trust can be sustained as participation grows and as community needs change over time.

Why federations where created
Universities, NRENs (National Research and Education Network), and other academic institutions joined together to form InCommon and eduGAIN so that students, faculty, and researchers wouldn’t need to create additional accounts to access resources used in their academic disciplines, research initiatives, and other collaborations involving people from multiple institutions, often from all over the world. In the research and education (R&E) community, federations are established at the national level. For example, InCommon is the federation in the U.S. and the Canadian Access Federation is the federation in Canada. eduGAIN is an interfederation service, interconnecting national federations and their participants to enable worldwide access to services and resources for the global R&E community.

Getting started

Authenticating users from other organizations in InCommon and eduGAIN involves the following activities:

Find identity providers in InCommon
Use the InCommon Federation Organizations list to find identity providers you can use to authenticate users from other institutions in the U.S.

Find other identity providers in eduGAIN
Use the REFEDS Metadata Explorer Tool to explore the national federations participating in eduGAIN and the identity providers you can use to authenticate users from institutions all over the world.

Choose a minimum set of required attributes
As a service provider, you decide what user attributes are required to provide your service to users, while the organizations you rely on to authenticate users decide what user attributes they are willing to release to you. User identifiers, names, and email addresses are often available. InCommon recommends you require only the attributes needed to operate your service. InCommon also recommends that organizations that authenticate users release at least one unique identifier to you by default. Additional required or optional attributes can be negotiated, based on your needs and the capabilities of the organizations you rely on to authenticate users. Learn more:

Design your service to integrate federation
You control the design of your service, including how it’s built, deployed, and where it’s hosted. You also control how your service enforces policies for authentication, authorization, and session management. When authenticating users from other organizations, your design is constrained only by the requirements for integration and use of federations. In particular, you must integrate, configure, run, and maintain software that meets the technical requirements included below.

Consume federation metadata daily
As a service provider, you only need to consume federation metadata for identity providers because other service providers aren’t useful for authenticating users. Therefore you can consume the “identity provider only” metadata published by InCommon. InCommon strongly recommends you refresh and verify federation metadata at least daily. Failure to do so can lead to operational problems and expose your service, users, and other participants to avoidable security and operational risks. How you consume federation metadata depends on the software you use and how the software is integrated into the services you provide. Learn more:

Adopt best practices for user experience
As a service provider, you control how users interact with your service, including when and how a user initiates the login process and selects the organization you rely on to authenticate them. A single “login” link or button at the top right corner of pages is a best practice. This link or button should lead to a simple interaction where users can find and select their home organization. Preferably, the list is organized to display the organizations you trust and that are willing to release user attributes to you. Additional best practices include displaying the image logos of these organizations and enabling users to “remember” the organization they selected to authenticate them. Learn more:

Register your service in InCommon and optionally eduGAIN
UW is a member of InCommon and can register services in the federation. The registration process begins with a request to UW-IT. We’ll help you register your service, including the choice of a permanent, unique, public identifier—known as your entityID—that identifies your service within the federation. For service providers that need to authenticate users from institutions outside the U.S., the registration process also enables you to register in eduGAIN. Learn more:

Request the release of attributes
Once your service is registered, you can request the release of user attributes from the organizations you rely on to authenticate users. If your service supports research and scholarship, InCommon recommends adopting the REFEDS Research & Scholarship Entity Category to enable more consistent release of attributes, without having to request attributes from each organization. You can also use the InCommon Federation Organizations list and REFEDS Metadata Explorer Tool to find email contact addresses for each organization, and email them to request the release of attributes. You can do this ahead of time, or as you onboard users from each new organization you rely on to authenticate users.
Fro more information:

Requirements for use of federations

Technical requirements
InCommon and eduGAIN use SAML (Security Assertion Markup Language) and the SAML V2.0 Web Browser SSO profile as the technical standards for security, interoperability, and trusted exchange of registration information about participating organizations and identity data about users. If you register a service with InCommon, you must provide registration information—known as SAML metadata—that conforms with the SAML standard. Other technical requirements include use of SSL/TLS to protect data in transit, and the ability to refresh and verify the digital signature on the SAML metadata published by InCommon at least daily. Learn more:

Data formats for attributes
InCommon and eduGAIN participants agree to use eduPerson and other standard data schemas to represent the attributes of users, including identifiers, names, affiliations, and email addresses. Learn more:

InCommon baseline expectations
If you register a service in InCommon, you’ll need to meet baseline expectations for user privacy, security practices, and maintenance of your registration information. InCommon is governed by its participants, who have established expectations for each other to sustain trustworthiness and accountability in day to day use. These baseline expectations apply to each kind of participant, including service providers that host and manage access to resources, institutions that authenticate members of their local communities, and federation operators and cyberinfrastructure like CILogon that connect participants and communities. Learn more:

Software recommendations

SAML service provider software
Shibboleth Service Provider software is highly recommended when authenticating users from multiple identity providers in InCommon or eduGAIN. Shibboleth is designed with these large federations in mind, and is used successfully throughout the R&E community. Other software implementations of SAML may not support secure configurations based on SAML metadata published by InCommon. Learn more:

Identity discovery software
If you use Shibboleth Service Provider software, the Shibboleth Embedded Discovery Service (EDS) software is recommended for implementing best practices for user experience. DiscoJuice is another software option for identity discovery that supports InCommon and eduGAIN. If those options don’t work for you, InCommon also offers a centralized service for general use. More information:

Other features of federations

Federation metadata
InCommon compiles and publishes the registration information—known as federation metadata—for all the services currently registered in InCommon and imported from eduGAIN. InCommon updates the federation metadata each weekday at 3pm Eastern time. The published information enables participants to find current registration information for other participants in one place, including the unique identifier (entityID) assigned during registration, as well as the current cryptographic keys used to sign and encrypt transactions (requests and responses) between participants. Therefore, federation metadata not only provides administrative contact information for participants, but also forms the basis for trust and interoperability among participants. Learn more:

REFEDS Multi-Factor Authentication Profile
If you provide a service that requires multi-factor authentication, you can use the REFEDS MFA Profile to request and verify that MFA has been performed by the organizations you rely on to authenticate users. The profile is defined to enable consistent adoption and use of MFA in the R&E community.

REFEDS Single-Factor Authentication Profile
While newer and less established than its MFA predecessor, the REFEDS SFA Profile is defined to enable consistent single-factor authentication across the R&E community.

Research & Scholarship Entity Category
If you provide a service that supports research and scholarship, adopting the Research and Scholarship Entity Category can facilitate the release of attributes from the organizations you rely on to authenticate users. This international standard specifies a set of attributes (user identifier, name, email) that many organizations agree to release to services that support research and scholarship. If you plan to provide access to users from a large number of organizations, adopting this entity category can enable more consistent release of attributes, without having to request attributes from each organization. Learn more:

SIRTFI for security incident response
If your service provides access to more sensitive data or operations, you can adopt the Security Incident Response Trust Framework for Federated Identity (SIRTFI) to coordinate incident response across organizations. SIRTFI is an international standard developed by the R&E community to identify organizations capable of effective participation in incident response, including agreed upon operational security standards, incident response, and traceability. By adopting SIRTFI, you can reduce the uncertainty in the security capabilities of the organizations you rely on to authenticate users, and grant more sensitive access to users from organizations that support SIRTFI. Learn more:

Alternative ways to use federations

Sponsor a partner organization into InCommon
If you partner with a software vendor, research community, or other organization that provides services within or to higher education, we can help you sponsor them into InCommon. Sponsorship by a participating institution like the UW is required for them to join. Learn more:

CILogon and Globus
If you provide services to or enable cyberinfrastructure (CI) for a research community, the CILogon and Globus services enable you to rely on InCommon and eduGAIN (as well as social login with Google and GitHub), without having to register your services in InCommon and without having to implement other technical requirements for federation. CILogon and Globus are already integrated into the federations, and you only need to integrate with one of them to authenticate users. Since they support the REFEDS Research & Scholarship Entity Category, many institutions already release attributes to them, further simplifying your adoption of federation.