Who should read: This article is for those who are responsible for the identity and access management infrastructure of their organizations, and would like to enable their users to access resources throughout InCommon.

Before we begin

This article provides onboarding guidance for an InCommon Federation Participant who wishes to register an Identity Provider. If your organization has not signed the InCommon Participation Agreement, please visit Joining the InCommon Federation.

If you are new to identity federations or to the research and education community, we recommend starting your journey by first reading A Primer on Identity Federation in Research and Education. It will provide important context to why InCommon works the way it does.

What is an Identity Provider?

An identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network.[wikipedia] 

In the InCommon Federation (InCommon), an identity provider specifically refers to a SAML IdPidentity provider (i.e, a single sign-on system that supports Security Assertion MarkUp Language). s registered in the InCommon Federation where its metadata (service information)  by a Participant where its SAML metadata is published in the InCommon metadata registry. 

Heads up: In casual conversation, an InCommon Participant who primarily participates as an IdP operator is frequently referred to as an identity provider. 

Understanding your Responsibility as an IdP Operator

The  InCommon Baseline Expectations for Trust in Federation (Baseline Expectations) is the foundational policy holding each InCommon Participant accountable when interoperating with each other. As an IdP operator, you are agreeing to the following:

• your IdP has the organizational authority and sufficient operating maturity to accurately authenticate and assert information about user when accessing a federated resource;
• you will maintain accurate, complete, and published IdP metadata via the InCommon Metadata Service to ensure timely and secured exchange of service connection and contact information; 
• you agree to follow common security incident response protocols to ensure speedy federation-related incident response coordination.

Further your IdP should support InCommon technical and interoperability standards when connecting to an InCommon-registered service provider. InCommon’s primary federated access protocol is the Security Assertion Markup Language (SAML). Additional deployment profiles and data exchange standards further clarify interoperability gaps missing from SAML:

• Working with user data
• Communicating identity assurance:  REFEDS Assurance Framework
• Communicating authentication assurance: REFEDS Assurance Profile
• Scaling responsible data release: REFEDS Entity Categories
• SAML V2.0 Deployment Profile for Federation Interoperability

Choosing the Right IdP Solution

My organization does not have an IdP, or I am looking for InCommon-ready software options.

The InCommon Trusted Access Platform offers a great suite of open-source, community-curated IAM software: Shibboleth (federated SSO), Grouper (group, role and access management), CoManage (virtual organization management), and midPoint (identity records provisioning). This standards-based software suite is optimized for use in InCommon. It is widely adopted among many InCommon participants.

My organization uses Microsoft Active Directory as our enterprise IdP. We’d like to connect to InCommon using Active Directory with ADFS. 

Microsoft Active Directory / ADFS does not  include all of the features required to enable you to fully interoperate in InCommon. There is a way to bridge the gap: ADFSToolkit, a Powershell module curated by a international R&E identity federation team, helps you configure ADFS to meet InCommon interoperability requirements.

If you would like to engage in additional consultation assistance, the InCommon Catalysts are excellent resources.

My organization uses Microsoft Entra (formerly Azure Active Directory) as our enterprise IdP. We’d like to connect to InCommon using Entra.

Microsoft Entra does not include all of the features required to enable you to fully interoperate in InCommon. To bridge these gaps, Microsoft offers a series of suggested solutions to integrate Azure AD with multilateral federations.

If you would like to engage in additional consultation assistance, the InCommon Catalysts are excellent resources.

My organization uses another commercial solution as our enterprise IdP…

The Linked SSO Working Group from the Community Architecture Committee for Trust and Identity publishes a report outlining connectivity options for several popular IdP solutions. To find out how your IdP solution can interoperate in InCommon, check out the Report from InCommon Linking SSO Working Group.

If you would like to engage in additional consultation assistance, the InCommon Catalysts are excellent resources.

Registering your IdP in InCommon

Registering an IdP means publishing your IdP’s SAML metadata in the InCommon Metadata Service. Doing so enables InCommon participants to securely exchange service information (metadata) with fellow participants at scale, allowing others to find your service easily, and reducing the need to individually negotiate integration setup. 

Your Site Administrator uses the Federation Manager to register metadata on your organization's behalf.

Site Administrators: See Introduction to Federation Manager to learn more.

Engage in Community Conversations

See Engage - get the most out of InCommon for information about how to keep current with new developments, augment your ability to interoperate within the federation, and become more involved in InCommon's vibrant community.