|Reinhard Müller 3be095f6ca Fix HTML conformance warning||1 month ago|
|doc||2 months ago|
|fsfe_cd_auth||1 month ago|
|tests||2 months ago|
|.dockerignore||2 months ago|
|.drone.yml||2 months ago|
|.gitignore||2 months ago|
|.isort.cfg||5 months ago|
|Dockerfile||6 months ago|
|Dockerfile-quality||4 months ago|
|LICENSE||6 months ago|
|MANIFEST.in||2 months ago|
|Makefile||2 months ago|
|Pipfile||3 months ago|
|Pipfile.lock||3 months ago|
|README.md||4 months ago|
|docker-compose-quality.yml||4 months ago|
|docker-compose.yml||5 months ago|
|setup.py||2 months ago|
The FSFE Community Database is a combined tool for donation management, administration of accounts for FSFE’s services, and opt-in based distribution of information emails.
All relevant data for these purposes is stored in a PostgreSQL database on the one hand and FSFE’s LDAP server on the other hand. Access to that data is encapsulated by the FSFE Community Database Backend (fsfe-cd-back), which provides both a set of commandline tools for manual administration tasks, and a protected RESTful(ish) network API to be used by other components.
The FSFE Community Database Authentication Server (fsfe-cd-auth) is an OpenID Connect Provider running on https://id.fsfe.org which authenticates a user against the LDAP server and then issues an access token which provides access to the authenticated user’s (and only the authenticated user’s) data though fsfe-cd-back’s API.
Finally, the FSFE Community Database Frontend is a web application through which the people stored in the database can manage their own data at https://my.fsfe.org. It sends users to fsfe-cd-auth to log in and then uses the user-bound access token returned from there to access the user’s data through fsfe-cd-back.
This repository contains the FSFE Community Database Authentication Server.
Currently, this is an incomplete implementation of the OpenID Connect standard, providing only those functions required by fsfe-cd-back and fsfe-cd-front.
Implementation is based on pyoidc with a thin Flask wrapper for the URL routing.
Authentication is possible with two distinct methods:
Authentication with username and password. Instead of the username, an email address can be given, in which case the corresponding username will be looked up via fsfe-cd-back. Username and password will be verified by a direct query to the LDAP server.
If only username or email address is given, but no password, then the user receives an email with a login token encapsulated in a link which will allow a one-time login. This method is not only helpful for resetting a forgotten password, it also allows users to log in who have not set a username.
doc contains more detailled documentation.