Many higher education institutions have adopted Okta as their primary identity and access management platform while continuing to rely on InCommon to connect their users with the broader research and education community.
Connecting the two, however, requires an additional piece of the identity architecture.
Okta recently published its InCommon adapter architecture, outlining architectural patterns for institutions that need to connect Okta with InCommon. The guide identifies Cirrus Identity as one of the primary federation adapter approaches for bridging these environments.
So why is a federation adapter necessary, and what does the architecture actually look like?
Yes. Okta can connect to InCommon using a federation adapter such as Cirrus Bridge or Shibboleth. The adapter bridges Okta's point-to-point federation model with the dynamic metadata and multilateral federation model used by InCommon. Cirrus Bridge provides this capability as a managed SaaS service.
For institutions that have moved authentication to Okta but still need to participate in InCommon, this allows Okta to remain the primary identity platform while the federation adapter handles the InCommon connection.
Okta and InCommon use different federation models.
Okta typically establishes point-to-point trust relationships between an identity provider and an application. This is known as bilateral federation.
InCommon operates differently.
InCommon uses multilateral federation, where participating identity providers and service providers rely on a shared trust framework and metadata service. Instead of configuring an individual relationship with every participating organization, institutions can use federation metadata to establish trust across the InCommon community.
As Okta explains in its architecture guide, Okta does not natively consume the dynamic metadata required for this model. A federation adapter therefore sits between Okta and InCommon and handles the federation-specific requirements.
For institutions using Cirrus Identity, there are two relevant approaches depending on the access use case:
Cirrus Bridge connects an institution's Okta environment to InCommon so its users can access InCommon-enabled services.
Cirrus Proxy enables users from InCommon and other trusted federations to access applications that otherwise may not support multilateral federation.
Let's look at each architecture.
Consider a university that has standardized authentication on Okta.
Students, faculty, and staff already authenticate through Okta to access institutional applications. But those same users may also need access to resources available through InCommon, including research services, library resources, and applications operated by other institutions.
This is where Cirrus Bridge fits.
Cirrus Bridge connects Okta to InCommon and eduGAIN so institutional users can access federated research and education services with their existing credentials.
Okta remains responsible for the institution's primary authentication experience, while Cirrus Bridge provides the connection between the institution's Okta environment and the multilateral federation.
In the architecture documented by Okta, Cirrus Bridge acts as the federation adapter between Okta and InCommon. Authentication continues through Okta while Bridge handles the federation-specific requirements needed to participate in the multilateral federation.
The result is that an institution can continue using Okta as its primary identity platform while participating in InCommon without operating its own federation adapter infrastructure.
For many institutions, moving to Okta does not necessarily eliminate their existing federation infrastructure.
An institution might use Okta for its primary authentication experience while continuing to operate Shibboleth specifically to support InCommon participation.
Both approaches can connect Okta with InCommon. The difference is largely operational.
Shibboleth is open-source software that an institution can host and manage itself. This provides institutions with control and flexibility, while also making the institution responsible for operating and maintaining the infrastructure.
Cirrus Bridge provides the federation adapter as a managed SaaS service instead. Okta's architecture guide distinguishes Cirrus's SaaS approach from the self-hosted Shibboleth approach and identifies factors such as infrastructure management, support and deployment as considerations when evaluating the two.
For institutions looking to reduce the amount of federation-specific infrastructure they operate, this creates another path:
Keep Okta as the primary identity platform while moving the InCommon federation layer to a managed service.
The University of Notre Dame used Cirrus Bridge as part of its transition to Okta while maintaining access to InCommon services.
[Read the Notre Dame customer story →]
There is another side to the federation problem.
What if an institution doesn't just need its own users to access InCommon resources?
What if it operates applications that need to be accessed by researchers, collaborators, or other users from other InCommon institutions?
A researcher at another university may already have a trusted institutional identity. Creating another username and password just to access your application introduces another account for the user and another identity for your institution to manage.
This is where Cirrus Proxy fits.
Cirrus Proxy connects applications to multilateral federation so researchers and collaborators can authenticate using credentials from their home institutions.
Cirrus Proxy handles the federation requirements and identity provider discovery needed to connect users from participating institutions with applications that may not support those capabilities directly.
That means researchers and collaborators can authenticate using credentials from their home institutions rather than requiring another institutional account solely to access the application.
The easiest way to understand the distinction is to look at which direction access needs to flow.
When your institutional users need to access InCommon resources:
Okta → Cirrus Bridge → InCommon
When InCommon users need to access applications protected by Okta:
InCommon → Cirrus Proxy → Okta → Applications
Bridge connects your identity provider to the federation.
Proxy connects federated identities to your applications.
In both cases, Cirrus provides the connection between enterprise identity technology and the multilateral federation environment.
This distinction matters because adopting a modern cloud identity provider does not eliminate an institution's need to participate in the research and education trust ecosystem.
Instead, the architectural question becomes:
How do you connect the identity platform you want to use with the federation infrastructure your users and applications still depend on?
There isn't one architecture that is right for every institution.
Some institutions have the infrastructure and internal expertise to continue operating Shibboleth. Others are looking to reduce the amount of identity infrastructure their teams need to host and maintain.
For institutions in the second group, a managed federation adapter can separate two concerns:
Okta handles the institution's core authentication experience.
Cirrus handles the multilateral federation connection.
This gives IAM teams a path to modernize their identity environment without giving up access to InCommon.
Okta's published architecture provides a useful technical reference for institutions evaluating these options and documents Cirrus as one of the approaches for connecting Okta environments with InCommon.
Okta can be used as an institution's primary identity provider while participating in InCommon, but a federation adapter is needed to bridge Okta with InCommon's multilateral federation model. Okta's published architecture identifies Cirrus Identity and Shibboleth as adapter approaches.
InCommon relies on multilateral federation and dynamic federation metadata. Okta's architecture is generally designed around point-to-point federation relationships and does not natively consume the dynamic metadata required for the InCommon model. The federation adapter handles that layer between the two environments.
Cirrus Bridge connects an institution's identity provider, such as Okta, to a multilateral federation such as InCommon or eduGAIN. Cirrus Proxy addresses the opposite access pattern, allowing users from trusted federations to access applications that may not natively support multilateral federation.
Cirrus Bridge and Shibboleth can both serve as federation adapter approaches between Okta and InCommon. The primary operational distinction is that Shibboleth is typically self-hosted and institution-managed, while Cirrus Bridge provides the federation adapter as a managed SaaS service. Which architecture makes sense depends on an institution's infrastructure, resources, technical requirements, and operating model.
Yes. Cirrus Bridge can connect institutional identity providers with multilateral research and education federations, including InCommon and eduGAIN.
If you're moving to Okta but still maintaining separate infrastructure for InCommon, Cirrus Bridge can provide the federation layer without requiring you to operate it yourself.
[See How Cirrus Bridge Works →]
[Talk to the Cirrus Team →]
For a deeper technical look at the architecture and authentication flows, read Okta's InCommon adapter architecture guide.