Episode 01- InCommon Federation- Introduction to InCommon

Have you heard about InCommon before? Come let’s learn about it. :)

InCommon

InCommon is a federation of organizations in the United States focusses on creating a common framework for trust in support of research education whose purpose is to facilitate collaboration through the sharing of protected resources based on trust.

There are three main participants in InCommon.

1. Higher Education Institutions
2. Research Organizations
3. Sponsored Partners

Organizations who wish to register in InCommon should sign an agreement with InCommon. Then they will be registered in InCommon after a verification process.

There are three services supported by InCommon.

1. InCommon Federation
2. InCommon Certificate Service
3. eduroam Service

For each service, there is a specific package in InCommon. Briefly, the charging process is done base on the number of service providers and identity providers in an organization.

In this blog, I am going to focus on Incommon federation.

InCommon Federation.

First, let’s see what is InCommon federation means.

According to the InCommon,

“The InCommon Federation is the US education and research identity federation, which provides a common framework for trusted shared management of access to online resources”

There are four roles associated with each organization who get registered in the InCommon.

1. InCommon Executive: responsible regarding all decisions and delegations of authority for the responsibilities of InCommon participants, all relevant federations and certificate services.
2. Federation Site Administrators: nominated by the InCommon executive who is responsible for registering and maintaining policies and technical data related to the organization’s participation in the InCommon Federation.
3. Delegated Administrators: responsible for submitting data related to the organization for the review by site administrators.
4. Billing Contact: who receives all the billing invoices from InCommon.

InCommon Federation has a web application named as “Federation Manager”. Organizational representatives engage with the federation through this web site.

An organization who is registered in the InCommon can have multiple service providers and identity providers.

In the trusted network Service Providers trust Identity Providers to provide accurate information, and Identity Providers trust Service Providers not to misuse the information they receive.

There are three main requirements that should be in each entity to support InCommon.

1. Compatibility of SAML V2.0: All the entities engage with InCommon should support SAML V2.0.
2. Support eduPerson Attributes: During authentication, InCommon federation requests for some eduPerson attributes.
3. Federation Metadata Refreshment: During federation, SPs and IdPs talk to each other. For that, they should know each other. It happens based on the metadata of each entity. For an uninterrupted service, entities should refresh the metadata regularly.

Metadata Management

Metadata management and refreshment processes are two of the most important processes in InCommon federation. The trust and communication between entities are based on this process.

During federation, entities should be identified by each other. For that, they exchange their metadata in a trusted manner. Each organization should submit metadata of the SPs’ and IdPs’ to the InCommon during the registration process uniquely.

There are 2 slightly different sets of metadata elements for SPs and IdPs. Entity ID is used to identify entities uniquely. There are some factors that should be considered when choosing an Entity ID.

In the beginning, InCommon had a very limited number of SPs and participants. But today it is a network with 765 organizations which consists of 555 IdPs and 4890 SPs.

Before talking about the services in the InCommon Federation, we need to understand what happens in InCommon federation.

Assume that there are two universities named University A (Uni A) and University B (Uni B) who are registered in InCommon.

Let’s take a scenario which the User A needs to access the service SP B which is in University B.

The flow of a user in accessing a Service Provider in InCommon

Step1: User tries to access service SP B.

Step2: As SP B does not know about the user A, it redirects the user into InCommon Discovery Service. (Details about the InCommon Discovery service will be discussed in a later blog)

Step3: User A will select his/her home organization(University A) and then the entity ID of the IdP A of University A will be sent to the SP B.

Step 4: SP B requests metadata of the IdP A from the metadata query service of InCommon.

Step 5: MDQ service sends the metadata related to the IdP A to the SP B.

Step 6: Then SP B sends an authentication request to IdP A.

Step 7: IdP A gets the entityID of the SP B from the authentication request and acquires metadata of SP B by requesting from MDQ service.

Step 8: MDQ service executes a query based on the entity ID and sends the metadata XML to the IdP A.

Step9: IdP loads the login page of the Organization A. Then the User A provides the credentials use in logging to University A.

Step 10: IdP A authenticates the User A.

Step 11: IdP A sends the authentication response to SP B.

Step 12: SP B decides whether to grant access or not. If everything is fine then the user can access the service.

I guess now you have an idea about the InCommon and its federation. I will discuss more details about the metadata service in my next blog.

References

Home Page - InCommon

InCommon Federation Library

incommon federation - Google Search