InCommon and Azure AD - 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. Azure AD does not support multilateral federation natively, but there are solutions available to fill the gap.
Azure AD and IAM Strategy
Many campuses are migrating to Azure AD as part of a Microsoft 365 deployment, or a “cloud-first” IT strategy, or to consolidate SSO and leverage Microsoft's robust security offerings including MFA, conditional access and adaptive authentication. In some cases, campuses continue to run Active Directory on premises, and synchronize account information to Azure AD. Other campuses are migrating all of their SSO infrastructure to the cloud, with Azure AD 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 significant downside of Azure AD 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 the multilateral limitation for Azure AD
- Provide an overview of solutions that support multilateral federation for Azure AD Identity Providers
Why Multilateral Federation?
Azure AD can be used to sign into 1000s of applications from the Azure App Gallery or into custom SAML applications. These types of integrations are called bilateral integrations - the Azure AD application administrator and the application owner exchange information on signing keys, URLs, attribute requirements and metadata to get the integration working.
Global Access is Key
What if you are a cross university research team developing an application and university researchers from around the world need to login? Do you need to contact hundreds of universities around the world to perform hundreds of bilateral integrations? 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?
In higher education there is such a trusted third party, the federation operator. The federation operator performs many tasks: It evaluates members, gathers metadata about their identity providers and service providers/applications, provides a framework for interoperability and many more tasks. In the United States the identity federation is InCommon, in Canada it is the Canadian Access Federation, the UK has the UK Access Management Federation, and most countries have a federation that participates in eduGAIN, a service to enable inter-federation access between national federations.
One major role of the federation operator is aggregating metadata (things such as signing keys, login URLs, contact information, supported encryption types, entity categories) about member applications and identity providers and making it securely available to their members. 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 a standard 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 Identity Provider independently.
Why Can’t I register my Azure AD IdP in InCommon?
Numerous federation participants want to use Azure AD as their primary authentication source for applications. The application gallery 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 Azure AD in a multilateral federation face several challenges, among them:
- Azure AD does not query or consume multilateral federation metadata.
- Federation IdPs like to define rules based on attributes in the federation metadata, such as REFEDS Research and Scholarship as described above, rather than the application itself. Azure AD has no equivalent mechanism.
- Federation rules require your SAML Identity Provider’s entityID to be a url in the school’s domain. The Azure AD SAML Identity Provider is in the windows.net domain and cannot be registered in the federation.
- Azure AD's signing key rollover policy does not mesh well with federation operator’s policies. Federation operators want IdPs to register new keys several days in advance of usage to provide time for the update to propagate to all members (a push approach). Azure AD recommends applications periodically pull metadata directly from Microsoft to learn about new signing keys.
- Non-premium Azure AD subscription levels do not allow the administrator to customize attribute release and instead release a default set. Service Providers in federation metadata (such as InCommon) expect these attributes to be named differently from the Azure defaults.
- Federation applications signal multifactor requirements in a way incompatible with Azure AD (see REFEDS MFA AuthN context).
- Federations have evolving baseline requirements for participation. Even if Microsoft updated Azure AD 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 Microsoft policy, account management, and engineering resources.
While Azure AD 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 Azure AD instance.
Multilateral Federation with Azure AD
Two of the most popular solutions for establishing a multilateral federation enabled Identity Provider are open source projects: Shibboleth and SimpleSAMLphp. Both can be deployed on premises or in the cloud. These solutions can be configured to authenticate against Azure AD, and integrate multilateral federation metadata for other Identity Providers and Service Providers.
Some campuses lack the internal staffing resources to run such projects in-house. To address that challenge, Cirrus Identity offers a cloud-hosted and fully managed Bridge solution. The Cirrus Bridge addresses the mismatches between Federation expectations and Azure AD capabilities. With the Cirrus Bridge, universities can use Azure AD as their primary IdP and participate in InCommon/eduGAIN. Because the Bridge is a managed service, universities don't have to allocate much IT resource to the service, and can focus on other priorities.
The Cirrus SAML Federation Adapter Bridge is now in the Azure AD Application Gallery - see the announcement and press release.
The Cirrus Bridge is registered as an application in Azure AD and as an IdP in InCommon. Using local and metadata driven policy, it can translate, transform and filter attribute data that comes from Azure AD 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 supports conditional access rules configured in Azure AD.
Cirrus Identity is a long-time member of the higher education and research identity management 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 InCommon Catalyst program.
Visit our site to learn more about Cirrus Identity and our services to support registration with identity federations.