InCommon and Okta - The Multilateral Federation Challenge
Multilateral federation facilitates collaboration across multiple organizations around the world. InCommon, CAF, UK Federation and all eduGAIN federations utilize multilateral federation. It is a critical component to Identity and Access Management architecture in higher education and research. Okta does not support multilateral federation natively, but there are solutions available to fill the gap.
Okta and IAM Strategy
Many campuses are migrating to Okta. They do so either as part of a “cloud-first” IT strategy; or to consolidate SSO and leverage other Okta solutions such as the Universal Directory, Lifecycle Management, or MFA. In some cases, campuses continue to run local credential stores and synchronize account information to Okta. Other campuses are migrating all of their SSO infrastructure to the cloud, with Okta at the center.
In an era of steep budget cuts and strained IAM teams, consolidating services and platforms makes a lot of sense.
However, one downside of Okta is that it does not directly support participation in multilateral federations like InCommon or other eduGAIN trust federations.
The goal of this post is to:
- Describe the value of multilateral federation for expediting service delivery across multiple organizations
- Explain why Okta does not support multilateral federation out-of-the-box
- Provide an overview of solutions that support multilateral federation for Okta Identity Providers
Why Multilateral Federation?
Okta SSO and Bilateral Trust
Okta can be used to sign into 1000s of applications listed in the Okta Integration Network (OIN) or into custom applications. These types of integrations are called bilateral integrations - the Okta application administrator and the application owner exchange information such as signing keys, URLs, attribute requirements, and metadata to get the integration working.
Multilateral Trust is Key to Global Access and Collaboration
What if you are a cross university research team developing an application that will be accessed by university researchers from around the world? Contacting hundreds of universities to perform hundreds of bilateral integrations is not practical. How would you even know who to contact? Could all of these tasks be handled by a trusted third party?
From the identity provider operator side at a university, do you want to evaluate, vet and configure every application that a researcher or student wants to use? These tasks would need to be replicated at thousands of schools. Could this also be handled by a trusted third party?
The Higher Education and Research community has developed a global network of identity federations to serve as that trusted third party. In the United States, the identity federation is InCommon, in Canada it is the Canadian Access Federation (CAF), and in Mexico, it is the La Federación de Identidad Mexicana (FENIX). European, Asian-Pacific, African, and South American countries also operate national research and education federations. Most national federations also participate in eduGAIN, a service to enable inter-federation access and between national federations.
Each national federation has a federation operator that performs many tasks:
- Evaluating member organizations
- Aggregating metadata about their identity providers and service providers/applications
- Providing a framework for interoperability and many more tasks
One major role of the federation operator is aggregating metadata such as signing keys, login URLs, contact information, supported encryption types, and entity categories. This metadata is aggregated and securely distributed for both member applications and identity providers (IdPs). This allows IdP operators to define general rules such as attribute release for specific “entity categories”. One such category that is already defined in federation metadata is for applications that meet the criteria for being “Research and Scholarship” applications. Identity Providers that participate in the federation can release an agreed upon set of attributes, such as email address, name and affiliation information, to those R&S-tagged services.
In sum, multilateral federation provides a trust framework that allows a Service Provider to trust hundreds of Identity Providers at once, without painstaking, time-consuming integration with each individual Identity Provider.
Why Can’t I register my Okta IdP in InCommon?
Numerous federation participants want to use Okta as their primary authentication source for applications. OIN makes it easy for them to add non-federation apps, the MFA support allows them to easily secure users, the rich policy rules allow them to control who can access what and when, and the reporting gives them insights into what applications are worth providing.
However participant schools that want to use Okta in a multilateral federation face several challenges, among them:
- Okta does not query or consume multilateral federation metadata.
- Each Okta SP/Application integration creates a unique SingleSignOn endpoint. InCommon expects you to register a single redirect SingleSignOn endpoint for an IdP.
- Federation IdPs like to define rules based on attributes in the federation metadata, such as the REFEDS Research and Scholarship attribute bundle as described above. Okta has no equivalent mechanism.
- Federation applications signal multifactor requirements in a way incompatible with Okta (see REFEDS MFA AuthN context).
- Federations have evolving baseline requirements for participation. Even if Okta updated solutions to meet the gaps described above, keeping pace with evolving standards and specs in the higher education and research IAM space would require ongoing allocation of Okta corporate policy, account management, and engineering resources.
While Okta does not integrate with multilateral federation, it does provide tools for adding custom SAML integrations. The trick is to bridge the gap between the Service Providers listed in federation SAML metadata and a given organization’s Okta instance.
Solutions for Multilateral Federation with Okta
Two of the most popular solutions for establishing a multilateral Identity Provider are open source projects: Shibboleth and SimpleSAMLphp. Both can be deployed locally or in the cloud to enable federation. These solutions can be configured to authenticate against Okta, and integrate multilateral federation metadata for other Identity Providers and Service Providers.
Cirrus Identity Solutions
Some campuses do not want to dedicate internal staffing resources to run such solutions in-house. To address that challenge, Cirrus Identity offers a cloud-hosted and fully managed Bridge solution. The Cirrus Bridge is a federation adapter that addresses the mismatches between Federation expectations and Okta capabilities. With the Cirrus Bridge, institutions can use Okta as their primary IdP and participate in InCommon/eduGAIN. Because the Bridge is a managed service, institutions don't have to allocate significant IT resources to the service, and can focus on other priorities.
The Cirrus Bridge is registered as an application in Okta and as an IdP in InCommon. Using local and metadata driven policy, it can translate, transform and filter attribute data that comes from Okta into the desired format needed by federation applications. The Cirrus Bridge supports REFEDS Research and Scholarship attribute release, as well as REFEDS MFA AuthN Context. The Cirrus Bridge also allows customers to bridge specific federation apps to specific Okta apps and thereby take advantage of even more of the Okta features they love (reporting, access policy, etc) with federation applications.
Cirrus Identity is a long-time member of the higher education and research identity management community and dedicated to delivering services for the community. We participated actively in the recent Identity Provider as a Service workgroup chartered by the InCommon Technical Advisory Committee. We are also one of the founding companies in the soon-to-be formalized InCommon Catalyst program.
Visit our site to learn more about Cirrus Identity services that support registration with identity federations and Talk to Us!