By Moritz Mühlenhoff, Staff Site Reliability Engineer, and John Bond, Staff Site Reliability Engineer
This is the first in a three-part series that will describe the introduction of Apereo CAS as an identity provider for single sign-on (SSO) in the services operated by the Wikimedia Foundation. Specifically, this post will cover the following topics:
- The original landscape of our web-based services before SSO was implemented
- The requirements we gathered for our new SSO identity provider
- A breakdown of the existing FLOSS solutions we evaluated
- A summary of why we picked Apereo CAS as the identity provider to build our new service
This article isn’t about the login system you can use to edit or read Wikipedia: The Wikimedia Foundation, the non-profit organization behind Wikipedia and other well known wiki-based projects, operates various web-based services which support the operation of its main sites, e.g. interfaces to our logging infrastructure, various monitoring and metrics systems, as well as a multitude of analytics tools used to support data-informed decision making. Some of these services are available to the general public (e.g. https://grafana.wikimedia.org/). Others are only available under a nondisclosure agreement (NDA), since they may contain personally identifiable information (PII) or other sensitive data.
In our original setup, we had no unified login for these services. Every service authenticated against the same backend data store (a replicated LDAP directory running on OpenLDAP), but every session was discrete, and users had to authenticate multiple times. Depending on the implementation of the authenticating service, users also needed to identify themselves with different user names. Some services required the “Wikimedia Developer Name.” Others needed the shell username (uid). This resulted in poor usability and was confusing for users.
The various authentication mechanisms also lacked support for multi-factor authentication, which meant that a compromise of a user’s password was enough to gain access to multiple services.
To address all these concerns we decided to evaluate and deploy a single sign-on (SSO) solution for our infrastructure and migrate our existing web services to it. We self-host our infrastructure in our data centers, and we strive to use open source tools over proprietary ones.
The following criteria were defined after initial discussion:
- The identity provider must be operated in our own infrastructure/data centers
- The solution needs to be free software / open source
- Provides an LDAP backend for retrieving our user/group data
- Support for SAML
- Support for U2F as a second factor
- Support for a redundant/HA setup spanning our two primary data centers in Virginia and Texas
Features that would be a major plus
- An active, community-oriented development process and a healthy project state
- Support for OpenID Connect
- Sensible logging that can be integrated into our monitoring infrastructure
- Support for TOTP/HOTP as a second factor
- Implemented in a programming language common to the Wikimedia SRE team
- Packaged in Debian (the Linux distribution we run Wikipedia on)
- Good documentation other than reading the code
In a subsequent step, we evaluated the landscape of existing open source solutions and decided to evaluate the following solutions in more depth (along with test installations). This evaluation started in late 2019.
Project website: https://lemonldap-ng.org
Development website: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng
Lemonldap::NG is a modular web SSO system mostly written in Perl. It’s a mature project with a long development history and is deployed on a number of large installations (such as France’s Gendarmerie Nationale with 240000 users).1
Project website: https://www.keycloak.org/
Development website: https://github.com/keycloak/keycloak
Keycloak is a project under the stewardship of Red Hat. It’s the underlying open source solution to their commercial “Red Hat SSO” project. It’s heavily based on JBoss and the underlying stack.
Project website: https://ipsilon-project.org/
Development website: https://pagure.io/ipsilon/
Ipsilon is also primarily developed by Red Hat engineers. There’s a Red Hat blog post where they scope Keycloak against Ipsilon: https://www.redhat.com/en/blog/red-hat-federation-story-ipsilon-keycloak-clash-titans.
Ipsilon is written in Python, and the most notable installation is the one powering the Fedora account service.
Project website: https://simplesamlphp.org/
Development website: https://simplesamlphp.org/support
SimpleSAMLPHP is an authentication framework written in PHP and primarily used in the educational/academic sector. Its focus is support for SAML, but other authentication methods are also supported.
Project website: https://wiki.shibboleth.net/confluence/display/IDP4/Home
Shibboleth is a Java-based SAML implementation that has its heritage in the academic world. It’s managed by the Shibboleth Consortium, which has its roots in the Internet2, and its development history dates back for two decades.
Project website: https://www.apereo.org/projects/cas
Development site: https://apereo.github.io/cas
CAS was originally developed at the University of Yale in early 2004 and development was eventually coordinated by the Apereo Foundation (originally named Jasig), a nonprofit organization formed by various educational organizations as members 2 CAS supports multiple authentication protocols (SAML, OIDC, and the CAS protocol for which it also provides the reference implementation) and is written in Java.
Based on the selection solutions, we deployed test installations in Wikimedia Cloud VPS . For every solution to be evaluated, an identity provider (IDP) was installed and configured to authenticate against LDAP. We also built a simple SAML dummy service to evaluate authentication and attribute release flows.
Following that evaluation, we settled on Apereo CAS. All solutions had their individual strengths, but for our use cases we found it to best address our needs, especially due to:
- A broad installation base of organizations with a wide range of feature demands, matching our current and future needs
- Good documentation. For other solutions, the docs were more limited and often required us to read up the source code, while the ones for CAS provided a good overview and sensible examples
- Very active development with regular releases (one full-time developer employed by the Apereo Foundation but also a healthy mix of other contributors)
- Complete support for high availability within the core design
In the second part of this blog series, we’ll describe the design and implementation of our Apereo CAS deployment, touching on aspects such as high availability, deployment on Debian systems, configuration management with Puppet, and monitoring/metrics collection.