Quelloffen · Selbst gehostet
Ein Login für alle
eure Anwendungen.
Limen ist ein selbst gehosteter Identitätsdienst nach OpenID Connect. Wiki, Cloud und Verwaltungswerkzeuge teilen sich ein Konto, eine Anmeldung und einen Ort, an dem Zugänge vergeben und wieder entzogen werden.
AGPL-3.0 Docker PostgreSQL Keine Cloud-Anbindung
- RS256
- signierte ID- und Access-Tokens
- PKCE
- Authorization Code Flow mit S256
- argon2id
- Passwort-Hashing nach OWASP-Empfehlung
- AGPL-3.0
- quelloffen, kein Lizenzschlüssel
Das Prinzip
Ein Konto statt sieben
Ohne zentralen Dienst führt jede Anwendung ihre eigene Nutzerliste. Neue Personen werden mehrfach angelegt, ausgeschiedene mehrfach vergessen. Limen sitzt einmal davor.
- Fachschafts-Wiki
- Fachschafts-Cloud
- Raumbuchung
- Wahl-Tool
- Inventar & Ausleihe
- Protokoll-Tool
Limen
Ein Konto, eine Anmeldung, ein Ort für Zugänge
Der Ablauf
Was bei einer Anmeldung passiert
Vier Schritte, die eure Anwendungen nicht selbst umsetzen müssen – jede gängige OIDC-Bibliothek beherrscht diesen Ablauf bereits.
- 01
Anwendung aufrufen
Jemand öffnet das Wiki. Die Anwendung erkennt: hier fehlt eine Anmeldung.
- 02
Weiterleitung zu Limen
Die Anwendung schickt den Browser an Limen – mit PKCE gesichert, damit der Rückweg nicht abgefangen werden kann.
- 03
Identität prüfen
Limen fragt Passwort und zweiten Faktor ab – oder erledigt beides in einem Schritt per Passkey.
- 04
Signierte Antwort
Die Anwendung erhält ein mit RS256 signiertes Token: wer angemeldet ist, seit wann, mit welchen Angaben.
Funktionen
Alles, was ein Identitätsdienst können muss
Und bewusst nichts darüber hinaus. Limen beantwortet die Frage „wer ist das?“ – was jemand darf, entscheidet jede Anwendung selbst.
-
OpenID Connect, wie im Standard
Authorization Code Flow mit PKCE, Discovery-Dokument und JWKS. Anwendungen binden Limen mit ihrer vorhandenen OIDC-Bibliothek an – ohne Sonderweg.
-
Passkeys und Zwei-Faktor
Anmeldung per Passwort mit TOTP-Code oder passwortlos per Passkey. Ein user-verifizierter Passkey deckt beide Faktoren in einem Schritt ab.
-
Konten an einer Stelle
Anlegen, bearbeiten, deaktivieren. Wer geht, verliert den Zugang zu allen angebundenen Anwendungen gleichzeitig – nicht nach und nach.
-
Schlüssel mit Karenzzeit
Signaturschlüssel lassen sich rotieren, ohne dass bereits ausgestellte Tokens ungültig werden. Der alte Schlüssel bleibt befristet im JWKS.
-
Nachvollziehbares Protokoll
Wer hat wann welches Konto angelegt, zurückgesetzt oder deaktiviert? Das Audit-Protokoll beantwortet das ohne Nachfragen.
-
Läuft auf eurem Server
Ein Docker-Container, eine PostgreSQL-Datenbank, nginx davor. Keine Verbindung nach außen, keine Nutzerzahl-Abrechnung.
Für alle im Team
Eine Anmeldung, die niemand erklären muss
Benutzername und Passwort – oder ein Fingerabdruck. Wer einen Passkey hinterlegt hat, meldet sich in einem Schritt an, ohne Passwort und ohne Code aus einer zweiten App.
- Passkeys über Touch ID, Windows Hello oder Sicherheitsschlüssel
- TOTP-Codes aus jeder Authenticator-App, plus einmalige Recovery-Codes
- Sperre nach zu vielen Fehlversuchen – pro Konto und pro Herkunftsadresse
Selbstverwaltung
Jede Person sieht, was mit ihrem Konto passiert
Unter „Mein Konto“ lassen sich Profil, Passwort und zweite Faktoren selbst pflegen. Zwei Ansichten dort ersparen der Verwaltung die meisten Rückfragen.
Verbundene Anwendungen
Welche Anwendung darf gerade auf das Konto zugreifen? Ein Klick entzieht die Berechtigung wieder. „Überall abmelden“ beendet in einem Zug alle Sitzungen auf allen Geräten.
Anmeldeaktivität
Erfolgreiche und fehlgeschlagene Versuche mit Zeitpunkt und Herkunftsadresse. Wer einen fremden Versuch bemerkt, sieht es hier zuerst – nicht erst, wenn etwas passiert ist.
Verwaltung
Zugänge vergeben und entziehen – an einer Stelle
Zugang haben ausschließlich Konten mit Administratorrechten – und auch die nur mit aktiver Zwei-Faktor-Sitzung. Wer bloß ein Passwort hat, kommt hier nicht hinein.
Registrierte Anwendungen
Jede Anwendung bekommt eine Client-ID und exakt festgelegte Redirect-URIs. Abweichende Rückleitungen weist Limen ab – ein offener Redirect entsteht so gar nicht erst.
Audit-Protokoll
Jede verwaltende Handlung wird festgehalten: wer, wann, an welchem Konto, von welcher Adresse. Nützlich bei Übergaben – und unverzichtbar, wenn doch einmal etwas zu klären ist.
Datenschutz
Anwendungen bekommen nur, was sie brauchen
Fremde Anwendungen fragen sichtbar um Erlaubnis. Und selbst dann werden nur die Angaben übermittelt, die für den angeforderten Scope vorgesehen sind.
-
Keine stillen Freigaben
Anwendungen, die nicht als „first party“ eingetragen sind, benötigen eine ausdrückliche Zustimmung. Die Liste der übermittelten Angaben steht im Klartext daneben.
-
Sparsam von Haus aus
Ohne den Scope „email“ erhält eine Anwendung keine E-Mail-Adresse. Die Adresse ist ohnehin optional – Konten ohne E-Mail funktionieren vollständig.
-
Nichts verlässt euren Server
Keine Telemetrie, keine externen Schriftarten, keine Abhängigkeit von einem Anbieter. Die Daten liegen in eurer PostgreSQL-Datenbank.
Betrieb
Ein Container, eine Datenbank, fertig
Compose zieht das fertige Image aus der GitHub Container Registry und startet es zusammen mit PostgreSQL – ein lokaler Build entfällt. Davor gehört nginx, das TLS übernimmt. Beim ersten Start legt Limen die Datenbankstruktur, den ersten Administrator und den Signaturschlüssel selbst an.
# 1. Konfiguration anlegen und Geheimnisse erzeugencp .env.example .envopenssl rand -hex 32 # AUTH_SECRETopenssl rand -hex 32 # ENCRYPTION_KEY# 2. Starten – Compose lädt das fertige Image, kein lokaler Build.# Migrationen, erster Admin und Signaturschlüssel laufen automatisch.docker compose up -d# 3. Health prüfencurl -s http://127.0.0.1:3000/api/health# {"status":"ok"}Häufige Fragen
Ist Limen das Richtige für euch?
Die ehrlichen Antworten – einschließlich der Fälle, in denen ein anderes Werkzeug besser passt.
Für wen ist Limen gedacht?
Für Organisationen, die mehrere eigene Web-Anwendungen betreiben und keine Lust auf getrennte Nutzerlisten haben: Fachschaften und Hochschulgruppen, Vereine, kleine Behörden, Agenturen, Forschungsgruppen. Die Grenze liegt eher bei „wie viele Anwendungen“ als bei „wie viele Personen“.
Was unterscheidet Limen von Keycloak oder Authentik?
Vor allem der Umfang. Limen macht Identität – Konten, Anmeldung, Profil – und sonst nichts. Es gibt keine Realms, keine Mandantenfähigkeit, keine Rollen-Engine. Autorisierung entscheidet jede Anwendung selbst auf Basis der gelieferten Identität. Das macht den Betrieb überschaubar, ist aber die falsche Wahl, wenn ihr Föderation über mehrere Organisationen oder SAML braucht.
Verwaltet Limen auch Rechte und Rollen?
Nein, bewusst nicht. Limen beantwortet die Frage „wer ist das?“ – nicht die Frage „was darf die Person?“. Die zweite Frage hängt vom Zusammenhang ab und wird in der jeweiligen Anwendung besser beantwortet.
Was passiert, wenn jemand die Organisation verlässt?
Das Konto wird in der Verwaltung deaktiviert. Die Anmeldung ist sofort gesperrt, bestehende Sitzungen und Refresh-Tokens verlieren ihre Gültigkeit. Es gibt keine Restzugänge, die in einzelnen Anwendungen übrig bleiben.
Braucht es einen E-Mail-Server?
Nein. Die E-Mail-Adresse ist ein optionales Profilfeld; es gibt keinen Versand von Bestätigungs- oder Zurücksetz-Mails. Passwörter setzt die Verwaltung zurück und gibt ein Erstpasswort aus – das ist bei kleinen Organisationen der ehrlichere Weg als eine Mail-Zustellkette.
Was kostet Limen?
Nichts. Limen steht unter der AGPL-3.0 zur Verfügung: nutzen, anpassen und weitergeben sind erlaubt, solange Änderungen unter derselben Lizenz zugänglich bleiben. Es gibt keinen Lizenzschlüssel und keine Funktionen, die hinter einer Bezahlschranke liegen.
Probiert es auf eurem eigenen Server aus
Quelloffen unter AGPL-3.0, ohne Registrierung und ohne Nutzerzahl-Abrechnung. Wenn es nicht passt, habt ihr eine Stunde investiert – mehr nicht.