Open Source for Open Knowledge
Wikimedia SSO: Evaluation
March 10, 2021
Site Reliability Engineering Moritz Mühlenhoff and John Bond
In the first of three posts about the implementation of Single Sign On (SSO). This post looks at the original landscape of Wikimedia’s web-based services, summarizes requirements for a new SSO provider, looks at existing FLOSS solutions, and explains why Apereo CAS was chosen.
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:
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. 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:
Strong requirements
Features that would be a major plus
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:
Development website:
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:
Development website:
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:
Development website:
Ipsilon is also primarily developed by Red Hat engineers. There’s a Red Hat blog post where they scope Keycloak against Ipsilon:​.
Ipsilon is written in Python, and the most notable installation is the one powering the Fedora account service.  
Project website:
Development website:
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:
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.
Apereo CAS
Project website:
Development site:
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:
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.
  2. ↩︎
About this post
Featured image credit: Locks and keys – a quintuple misfit, Franz van Duns, CC BY-SA 4.0
Apereo CAS Open Sourcesingle sign-on sso
1 thought on “Wikimedia SSO: Evaluation”
hasan says:
JUNE 8, 2021 AT 8:32 AM
Hi, First of all i will say about is the non-profit organization and give many way to writer and informer in easy way and also give many project for user
easy while other such as site face many different problem so i will thanks Wikimedia
give easy for information.
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.
Notify me of follow-up comments by email.
Notify me of new posts by email.
Profiling PHP in production at scale
Upgrading Hadoop in just one day
Privacy Policy | About
Wikipedia® and other Wikimedia project names and logos are registered trademarks of the Wikimedia Foundation, a non-profit organization.
Unless otherwise stated content is licensed under a CC BY-SA 4.0 international license.
Powered by VIP, Automattic Privacy Notice.
Learn more about the
Wikimedia Foundation
Follow us on Twitter @wikimediatech