By Andrew Klaus, former security advisor, Cybera
Cybera is working on a two year pilot to create an Identity Federation for K-12 schools in Alberta, called myUnifiED. This Identity Federation will use OpenConext, an open source hub and spoke federation platform, as the technical solution. In this three part blog series, I will detail the tools and procedures that we use to deploy and manage myUnifiED.
What is an identity federation?
An identity federation, to give a high level overview, is a way of separating authentication systems (Identity Providers) from systems that provide services (Service Providers). It relies on mutual trust between the Identity Provider (IdP) and the Service Provider (SP). The IdP must trust the SP with handling the user’s information, and the SP must trust the IdP with recognizing that a user is who they say they are.
What is OpenConext?
OpenConext is a federation platform created in 2010 by SURFnet (the Research and Education Network for the Netherlands). Its entire codebase is hosted on GitHub, including an automation toolset that can be used to easily bring up a new federation. OpenConext is primarily used to run SURFnet’s own Identity Federation, SURFconext.
At the very core of OpenConext is EngineBlock and the Service Registry (also known as Janus). The easiest way to describe EngineBlock is that it’s a proxy to handle authentication requests between SPs and IdPs. Because of the hub and spoke model of the federation, each SP and IdP only needs to connect to a single endpoint (EngineBlock) to be part of the federation. The Service Registry is a simpler concept that is used to manage EngineBlock’s data. This includes all SP and IdP metadata, as well as the ability to limit certain IdPs to access certain SPs.
While these are the minimal feature-sets that OpenConext requires to function, it also includes other useful features that Cybera has yet to experiment with, and therefore won’t cover in this series. These include:
- Authorization Rules that provide access to SPs based on user attributes. This is useful if the SP doesn’t have this sort of fine-grained control (Ex. Only allowing teachers with from school X to access Service Y).
- OIDC and voot, which provide OpenID Connect and OAuth support to the federation.
- Stepup, which adds multi-factor authentication abilities when required by specific services.
Tools Used
All tools we use are open source and free to use by anyone. These are the tools that will be outlined in this series:
- Ansible: Used by OpenConext for deployment, we use this tool for both configuration and maintenance.
- Terraform: Automates the building and rebuilding of infrastructure components. Because everything is stored in a version control system, it keeps track of any changes made to infrastructure (such as rebuilding of instances or increasing CPU/memory).
- OpenStack: Our Rapid Access Cloud uses OpenStack, and we make use of the Dynamic Inventory component of Ansible (developed for OpenStack) to automate configuration.
In OpenConext Deployment: Part #2 I will explain how to build the support infrastructure to configure OpenConext on.