|Reinhard Müller a7448f9af1 Get rid of .env file in standard configuration.||3 days ago|
|doc||3 days ago|
|fsfe_cd_auth||3 days ago|
|tests||1 week ago|
|.dockerignore||3 days ago|
|.drone.yml||3 days ago|
|.gitignore||3 days ago|
|.isort.cfg||3 months ago|
|Dockerfile||4 months ago|
|Dockerfile-quality||2 months ago|
|LICENSE||4 months ago|
|MANIFEST.in||3 days ago|
|Makefile||3 days ago|
|Pipfile||1 month ago|
|Pipfile.lock||1 month ago|
|README.md||2 months ago|
|docker-compose-quality.yml||2 months ago|
|docker-compose.yml||3 months ago|
|setup.py||3 days 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.