by Jim Basney
I once was a true believer in the end-to-end multi-lateral federation vision: that metadata about IdPs and SPs enables authentication by users from thousands of organizations to thousands of services. To make this vision a reality, we work to scale the SAML metadata and decentralize the OIDC metadata, and we develop community profiles for scalable interoperability.
This vision is an attractive ideal, but we all know the reality is more complicated. Less than 15% of eduGAIN IdPs support multi-lateral federation for research and scholarship services. Even when working with those IdPs, SPs still face challenges. For example, some IdPs change users’ eduPersonTargetedID values when upgrading their Shibboleth software. The challenges are not unique to eduGAIN. In 2015 my Google ID changed from AItOawkMwlXe9BuV6E5grv-8DX8r7OftrrkjaXk to 111661672296878757956. In 2017 my ORCID iD changed from http://orcid.org/0000-0002-0139-0640 to https://orcid.org/0000-0002-0139-0640.
As the AARC Blueprint Architecture tells us, we need an IdP-SP Proxy to help applications with these challenges. The proxy combines an externally-facing SP that handles the complexities of multi-lateral federation together with an internally-facing IdP that provides the identifier and other user attributes that applications require. Applications benefit from the simplicity of a single IdP (the proxy) that provides stable and reliable authentication, relying on the proxy operators to troubleshoot problems centrally on behalf of all the applications served by the proxy. The proxy can manage complexities like identity linking (e.g., allowing users to transition from one IdP to another when moving between universities), attribute enrichment (e.g., managing user attributes such as group memberships that are specific to a research collaboration and unknown to university IdPs), and protocol translation (e.g., so an OIDC-enabled service can use SAML authentication). The proxy delivers the power of federated identity to the application while hiding the complexity.
It should be no surprise that a proxy operator like me thinks that these proxy services should be first class participants in our Federation 2.0 vision, giving attention to the ways in which proxies differ from other SPs. We need clear, discoverable policies for proxy operations (using the Snctfi policy framework), and we need good practices around managing user attributes in the proxy (following the voPerson recommendations). As a growing number of applications connect to federations via a proxy, we need to include proxies in our federation support and sustainability models. Let’s embrace the role of proxy services in delivering Federation 2.0 to the wide range of services that our users want to access!