Bits of Freedom
Bits of Freedom

Tinkerer and thinker on everything free and open. Exploring possibilities and engaging with new opportunities to instigate change.

Jonas Öberg

Jonas is a dad, husband, tinkerer, thinker and traveler. He's passionate about the future and bringing people together, from all fields of free and open.


My Newsletters

If you're interested in what Commons Machinery,, or myself are up to, I'd love for you to be part of my notification lists. It's pretty low volume, a few messages per month, depending on which notifications you sign up for. Thanks for taking an interest!

Read more & subscribe

Something insightful, etc.

Jonas ÖbergJonas Öberg

I had big plans to write something insightful (or equally likely something completely irrelevant) about free and open source software today, but something else has occupied a more significant part of this week: technology.

As the FSFE's executive director, I'm also coordinating some of our technical work, an often overlooked but nonetheless important area of our activities to keep our backends running and supporting our policy, legal and outreach work.

Some months ago, two of our technical interns (Lusy and Luke) started with a massive rewrite of our account management system, a central piece of our infrastructure which include both authentication and authorization systems as well as donations and supporter contributions.

This work comes not only with a rewrite of the existing functionality but with new requirements to beef up security and re-think our system for building and deploying our infrastructure tools.

Our new account management system has been broken down into three separate parts. We've also taken the liberty of introducing two new components which simplify some parts of this. Let's walk them through one by one, starting with the two new components, which will be generally useful for all FSFE services.

These are all in a state of flux at the moment, and the challenge over the next weeks will be to tie these components together and make sure they actually work seamlessly.


The fsfe-rp is a reverse proxy which handles SSL termination. Essentially, requests made to any FSFE service is first terminated at the fsfe-rp which manages SSL certificates and then sends on the request internally to the right service node. The reply then goes back through the fsfe-rp to the requester.

Like all of the other tools, fsfe-rp is built into a Docker image and updates are deployed with Ansible.


Coupled with our reverse proxy is a specific tool that uses LetsEncrypt to generate and update SSL certificates for any of the domains handled by the fsfe-rp. This is built using Yves Blusseau's LetsEncrypt companion for nginx-proxy and is very convenient, though at present it only supports services running on the same host.


This is perhaps the part which reminds most of the previous account management system: the frontend. This version though is written in Flask with Jinja2 and Babel. The frontend doesn't do any authentication in itself, it relies on the user being logged in and authenticated by our oidcp, which comes next. The frontend also doesn't have any information about the individual users but rely on the fsfe-cd service (explained later) for this.


Whenever someone wants to login to the FSFE systems (or at least the account management system, though we hope to expand this to other systems eventually), they're redirected to the oidcp which is our OpenID Connect Provider. The oidcp is responsible for authenticating the user against our backend LDAP. In exchange for a successful authentication, the user session is provided with an id token (technically an access token which is then exchanged for an id token) which is a digitally signed token containing the user credentials.


From the perspective of the ams-frontend, the fsfe-cd is its backend. Its from the fsfe-cd the frontend gets information about the user: their name, supporter number, address (if specified) and so on. And its the fsfe-cd which is called when a user wants to update their information.

To prevent fsfe-cd handing out data for anyone to the frontend, the frontend must provide fsfe-cd with the id token of the signed in user. By checking the digital signature (and also verifying the token with the oidcp), the fsfe-cd can allow the frontend to read/write information pertaining to the user for which the id token has been created.

This means that for the asm-frontend to be able to read the user details of user fred, user fred must previously (and not long enough that it has expired) signed in and authenticated themselves with the oidcp so the frontend gets an id token to use as authentication.

As said, over the next weeks, we'll be tying these components together and work more on deployment and integration. With some luck, we'll have the first version of the account management system in place by the end of next month!

Jonas Öberg

Jonas Öberg

Jonas is a dad, husband, tinkerer, thinker and traveler. He's passionate about the future and bringing people together, from all fields of free and open.