Preserving the R&E Federation Trust Ecosystem in a Multi-Protocol Future

Background

Fifteen to twenty years ago, the research and education (R&E) community was one of the first to avail itself of federated identity, where services provided by one institution utilize other institutions’ identity providers to support collaboration and shared services among universities and their partners. The Security Assertion and Markup Language (SAML) was chosen as the protocol for R&E federations, because of its ability to support R&E’s use cases well.

Since that time, the OpenID Connect (OIDC) protocol, and more recently, Verifiable Credentials (VCs), have emerged as alternatives to SAML. Across the entire Internet community, OIDC is now often the preferred choice for utilizing federated identity, and use of VCs is expected to achieve similar popularity in the future.

In this paper, I will discuss a potential high-level architecture for a multi-platform R&E federation that shares a common, policy framework infrastructure to foster trust (i.e., willingness of identity providers and services providers to exchange identity information) across all of its component platforms. In this context, I define a platform as a deployment of a protocol such as SAML or OIDC. Interoperation and common policy within a platform are assumed. Interoperation and common policy between platforms, however, are not assumed, even when they are based on the same protocol. For example, a service provider that expects an OIDC token from Google’s platform will not trust an OIDC token from Facebook’s platform, and agreeing to Google’s policy terms means nothing to Facebook.

Considering an Architecture for Multi-Platform R&E Federations

Background

Fifteen to twenty years ago, the research and education (R&E) community was one of the first to avail itself of federated identity, where service providers utilize other institutions’ identity providers to support collaboration and shared services among universities and their partners. The Security Assertion and Markup Language (SAML) was chosen as the protocol for R&E federations, because of its ability to support R&E’s use cases well.

Since that time, the OpenID Connect (OIDC) protocol, and more recently, Verifiable Credentials (VCs), have emerged as alternatives to SAML. Across the entire Internet community, OIDC is now often the preferred choice for utilizing federated identity, and use of VCs is expected to achieve similar popularity in the future.

In this paper, I will discuss a potential high-level architecture for a multi-platform R&E federation that shares a common, policy framework to foster trust (i.e., willingness of identity providers and services providers to exchange identity information) across all of its component platforms. In this context, I define a platform as a deployment of a protocol such as SAML or OIDC. Interoperation and common policy within a platform are assumed. Interoperation and common policy between platforms, however, are not assumed, even when they are based on the same protocol. For example, a service provider that expects an OIDC token from Google’s platform will not accept an OIDC token from Facebook’s platform, and agreeing to Google’s terms means nothing to Facebook.

Reconsidering the Architecture of R&E Federations

[Note: This post was revised and republished on October 3, 2023 as Considering an Architecture for Multi-Protocol R&E Federations.]

Background

Fifteen to twenty years ago, the research and education (R&E) community was one of the first to avail itself of federated identity, where Service Providers (SPs) utilize other institutions’ Identity Providers (IdPs) to support collaboration and shared services among universities and their partners. The Security Assertion and Markup Language (SAML) was chosen as the protocol for R&E federations, because of its ability to support R&E’s “multilateral” use cases well.

Since that time, the OpenID Connect (OIDC) protocol, and more recently, Verifiable Credentials (VCs), have emerged as alternatives to SAML. Across the entire Internet community, OIDC is now often the preferred choice for utilizing federated identity, and use of VCs is expected to achieve similar popularity in the future. It behooves the R&E community to leverage these newer protocols.

Thoughts about Proxies and Federation Trust Models

It seems that whenever I’m in a discussion of the benefits of introducing Identity Provider or Service Provider proxies into the federation I say something like “Yeah, but it impacts the trust model,” at some point. I think it’s time for me to be more explicit.

Exploring Silicon Valley History

I was recently reminded of my birthday outing to some of Silicon Valley’s historic locations. At the time, I had planned to post some of the photos I took, but 2020’s global events distracted me. Nevertheless, better late than never…

EasyFed: Simple Orchestration for Multiple Authentication Services

Integrating federated authentication methods like SAML and OIDC and federations like InCommon into Internet-accessible services is not easy. While software libraries and documentation are amply available to integrate with each method or federation, they can be complex to deploy, and there is almost no help for developers who must support multiple methods and federations.

This, unfortunately, has significantly inhibited the the growth of services that leverage federated identity. Commercial providers, in particular, are understandably loath to invest in the startup cost of supporting a federation unless there is clear evidence of revenue growth from the federation’s participating institutions. This is true despite the fact that those services’ authentication requirements are often simple and straightforward.

This post suggests an approach to address this issue. The ideas are very much in a formative stage, so please comment.

Walkers and Hunts Paint the Town Red

Marty, Sighle, Julie, Vince, Emma, Tammy, and I gathered last weekend (November 15-17) in Redlands to celebrate the life of our patriarch, Jack Walker, who passed away earlier in the year. Our tears had already been shed; his affairs had been addressed; this was the time for us to remember the good times we’ve had in the places we had them.

7 Things You Should Know About Federated Identity

A short paper I participated in authoring for EDUCAUSE: 7 Things You Should Know About Federated Identity

Thoughts about Discovery for Multi-Lateral Federation

There has been considerable discussion of “Discovery 2.0,” a reassessment of SAML discovery services in light of the current move away from the distribution of fully-aggregated metadata about Identity Providers (IdPs) and Service Providers (SPs) to per-entity distribution via the MDQ protocol. The need to address this issue was highlighted in the Final Report of the Per-Entity Metadata Working Group, but it was a well-known issue prior to that, and the issue of user experience for discovery was the topic of the RA21 meeting in San Francisco as recently as last week.

This blog post questions our current discovery paradigm and suggests an alternate approach.

Network Neutrality and Public Services

There’s been a lot of talk recently about the impact a loss of net neutrality would have on businesses, both large and small, that market their services over the Internet. The actions contemplated by the FCC, ostensibly to encourage innovation by broadband Internet providers, will have the opposite effect on those businesses. This is true not only because those businesses will experience higher Internet pricing (which, presumably, they will pass on to their customers), but also because they will need to enter into service agreements with all broadband Internet providers that connect their customers.

But what about your child’s school? Your public library?