Federation 2.0
by Tom Barton, University of Chicago and Internet2
“Authenticate locally, authorize globally” was the rallying cry of those who originally conceived of what we now called identity federation. Deliver good user experience by extending the reach of campus credentials far beyond where the campus can take them, and simultaneously reduce the number of credentials users need to deal with. Leverage campus credential management practices to produce a dividend for relying parties, who could then focus more of their energy on their services. Make federation a global infrastructure so that academic collaboration, itself global, benefits.
How’s that been going, and what should we do differently going forward?
The “authorize globally” part has proved rather hard. Access policies are built either by listing individual users or performing a check on their attributes (or attributes of their credential management practices). The value of federation per se is constrained by the availability of valuable attributes it conveys. The difficulty in identifying the most valuable attributes and the change management to produce them scales directly with federation’s reach; these are considerable ongoing challenges.
For a long while needs and issues like these were conceived only in the context of a singular infrastructure: global R&E federation, i.e., the infrastructure operated by the national R&E federations. Support more users, i.e., support more academic collaborations, by getting more campuses into federation, and somehow induce each one to improve its credential management practices to source valuable attributes and keep abreast of best practices, their share of enabling “authorize globally”.
Driven by these challenges, gradually the conception of federation began to evolve. Some national R&E federations centralized the federation operations of their member campuses, reducing the change management problem (though sometimes creating other issues in the process). Social ID gateways admitted users without waiting on their campus Central IT to get on board with federation, the “long tail” problem of the original conception of federation. Credential providers for unaffiliated users started to pop up. Research e-infrastructures experimented with proxies as a more efficient means to extend the value of federation across an existing system of research services compared to retrofitting each research service to weather federation on its own. These proxies also provided a platform on which to mitigate attribute deficiencies of national R&E federations and address the long tail problem, at least for their users, sometimes by relying on ORCID as a credential provider. CILogon, Globus Auth, and other services specialized in the niche of linking accounts, translating tokens, and other weather proofing between R&E federation and research e-infrastructure, permitting proxies to further specialize in how authorization is managed. Additional federating technologies, OAuth/OIDC and Moonshot, began to rise to address use cases ill-suited to SAML implementations, or due to their own momentum. And the sheer scale of R&E federation has begun to bog down the means by which federation operators have been managing their members’ SAML metadata, prompting a shift in this fundamental process a step in the direction of how it’s proposed to be done for OIDC.
This is what federation has been becoming, an ecosystem much richer than what we could conceive at the outset. Shifting our focus from the original to this evolved conception of federation yields implications for what we should do differently. Here are a few such thoughts.
Federation metadata
Static metadata files represent what’s in R&E SAML federation, and practices followed by federation operators to sign and manage metadata are foundational to the trust model. As delivery of SAML entity metadata shifts to per-entity and “just in time”, some of these practices will need to shift accordingly. Each entity’s metadata will need to be individually signed in a manner that attests its compliance with the corresponding federation operator’s policies; hence, operational practices implementing trust will become separable from those providing delivery of trusted metadata. That will create the opportunity for new parties to provide metadata delivery services, or to deliver just their own. Existing federation operators will need to decide how their foundational trust practices will be implemented in this environment.
This also means that the SAML metadata situation is becoming much the same as proposed for OIDC metadata statements. There is value in converging on a common model for managing trusted metadata of both sorts, so that effort need not be spent running parallel versions of essentially the same processes. That will require a healthy injection of delegation into current metadata management, discussed further below.
Delegate to scale
More types of organizations are becoming involved in making federation happen than there used to be, and each needs some well-defined way to add their bit of authority to the overall ecosystem that federation is becoming. Thoughtful delegation for each new type of role maintains the trust and integrity of the integrated assemblage.
The long tail problem, at least in the US, is one of scale, beyond the reach of the federation operator alone, or any single organization. Scaling problems need a layered approach, and adding a layer while preserving trust requires appropriate delegation of authority, articulation of processes, and corresponding accountability. InCommon developed such a model, backed by contractual terms and conditions, by which suitably designated “Stewards” can create InCommon entities.
Evolving management of SAML or OIDC metadata needs a delegation component as well. Can InCommon’s Stewards model be adapted for the purpose of enabling a variety of organizations to manage and deliver metadata, their own or for a specific constituency, on behalf of one or more established R&E federations?
Proxy operators interface the federation world with another ecosystem, an e-infrastructure. They need to be able to act within global federation on behalf of proxied research services. AARC and Security for Collaborating Infrastructures (SCI) have been developing the formal policies and procedures needed to delegate to proxies the authority to act in R&E federation on behalf of proxied services. Some national R&E federations need to adjust their membership criteria and on-boarding processes to reflect the evolving conception of R&E federation and permit proxies to join. Similarly, some proxies, and some organizations, fall outside of any single national jurisdiction. R&E federation needs to make a well known procedure for them to join.
Need for speed
The original model, that every home organization operates its own federated credential provider, is broken. Structural change cannot be propagated across so many organizations in a determinant time frame, and not quickly enough to respond to needs that motivate the changes in the first place. The problem is made worse by fiscal pressures that reduce the ability of some organizations to maintain the skills and resources to keep up with federation best practices. There are at least two ways this can be addressed, and academic collaboration will be best served if both happen.
First is to recognize and incorporate some characteristics of hub and spoke federations into the larger mesh federations. Federations that provide a quality IdP/OP as a Service, connected to subscribers’ campus authentication and attribute services, reduce the time to implement best practice changes because they do it themselves on behalf of those of their members that subscribe to the service. This also reduces the long tail problem by reducing the burden on prospective members to have an IdP presenting their users to federated services.
The second is to sustain a sufficient set of credential service providers for unaffiliated users, effectively incorporating this part of the ecosystem into the R&E federation platform so that services built on that platform can rely on those services to be there for the long haul. Think ORCID, CILogon, and the like. How will we know what’s “sufficient”? That depends on how we think of the mission of the R&E federation platform – see further below.
Trust in federation
As more layers are added and more parties have more roles in making federation happen, it is even harder to understand why and how much the ecosystem should be trusted. It starts with the metadata bearing a cryptographically nonrepudiable attestation that federation policy has been followed. Beyond current national R&E federation policies, what more is needed in order to have high confidence in federation?
For one, we need to know what to do when things go wrong, how to manage a security incident. Sirtfi must become very widely adopted; however, the original model, that each national R&E federation undertake matters like this, is not meeting that need. How should CSIRTs, where they exist, be connected with federation? Some evolution of the security incident response status quo is needed.
We can’t have contracts between all pairs of organizations participating in federation to stand in place of our need for trust. What we do have is some faith in our community stemming from our shared mission of making The Academy work. That faith needs some structure and process to become a foundation for trust in federation. InCommon is experimenting with a set of Baseline Expectations of members and the federation operator and an associated set of open, participative processes that it is hoped will manufacture trust out of our faith in each other. If it works, it should be expanded and adapted to work across all of global federation.
Conclusion
The concept of federation has evolved from one comprised of organizations that operate federated endpoints and national organizations in which they are enrolled. It is still becoming a far more complex ecosystem in which more parties have a substantial role in making “authenticate locally, authorize globally” actually happen. Our models for how organizations, technologies, processes, and policies support and enable this ecosystem must evolve with it. It is already possible to discern the need to change how federation metadata is managed, add delegation into some policies and processes, provide well-chosen centralized services, and adopt processes that secure and promote trust in this ecosystem.
Over the time that we’ve all been working on federation, there have been periods in which we confused ourselves about why we bother doing this federation stuff. Looking forward and thinking about next steps, it’s important to start by recalling what we are aiming to accomplish. The original motivation described at the start of this article is still a good one:
Extend the reach of campus credentials far beyond what a campus can do for itself with a global access management infrastructure supporting academic collaboration so that users and academic service providers can focus on the academic mission.
So to go forward, the very first step is to reconfirm with each other whether this is what we think we’re all trying to accomplish.