Zum Inhalt springen

Open Source

Wir bauen offen — und nutzen es selbst

Komponenten, die fast jedes System braucht, bauen wir einmal und offen. Aktuell zwei Projekte: CentralAuth für die Authentifizierung und SancMeld für den Abgleich mit Sanktionslisten.

CentralAuth

Proof of concept

Ein Autorisierungsserver und ein BFF für alle Projekte

Jedes neue Projekt schreibt Login, Session-Verwaltung und das Gateway vor seiner API üblicherweise von Neuem. CentralAuth dreht das um: Ein neues Projekt registriert sich einfach und bekommt seine Frontends und Backends vom ersten Tag an abgesichert.

Neues Projekt

Drei Schritte statt einer Woche Arbeit

Login, Session-Erneuerung, Logout, Berechtigungsprüfung, Gateway vor der API — in jedem neuen Projekt dieselbe Arbeit. Hier ersetzt sie die Registrierung der Anwendung.

  1. Registrieren Sie die Anwendung

    Code, Name und interne Adresse des Dienstes. Der Pfad /bff/{code} entsteht automatisch.

  2. Lassen Sie das Backend verborgen

    Der Dienst läuft im internen Netz ohne exponierten Port. Von außen führt kein Weg an ihm vorbei außer über das BFF.

  3. Das Frontend ruft über das BFF auf

    Aufrufe gehen an /bff/{code}/… mit dem Login-Cookie. Im Projekt kommt keine einzige Zeile Authentifizierungscode dazu.

Identität

Autorisierungsserver

Ein Ort, an dem das Login für alle Anwendungen gelöst wird.

  • OpenID Connect und OAuth 2.0 auf Basis von OpenIddict
  • Authorization Code mit verpflichtendem PKCE und Refresh Tokens
  • E-Mail und Passwort über ASP.NET Identity, dazu externes Login über Google
  • API-Schlüssel für die Kommunikation zwischen Diensten ohne Benutzer
Sicherheit

Zentrales BFF

Der Token gelangt nicht in den Browser. Niemals.

  • Der Browser hält nur ein HttpOnly cookie — im localStorage gibt es nichts zu stehlen
  • Der Proxy tauscht die Session erst auf dem Weg zur API gegen einen kurzlebigen JWT
  • Anfragen werden eins zu eins weitergeleitet — samt Body, Headern und Statuscodes
  • Bei Entwicklung und Debugging sehen Sie die realen API-Aufrufe, Fehler müssen nicht über Schichten hinweg gesucht werden
  • Interne APIs brauchen überhaupt keinen ins Internet exponierten Port
Onboarding

Registrierung von Anwendungen

Eine neue Anwendung ist ein Eintrag, nicht ein weiteres Stück Konfiguration.

  • Die Registrierung einer Anwendung erzeugt automatisch den Pfad /bff/{code}
  • Pfade liegen in der Datenbank, nicht in einer Konfigurationsdatei — Änderungen ohne Deployment
  • Ein Projekt kann mehrere Frontends und Backend-Dienste haben
  • Laufende Verfügbarkeitsprüfung der registrierten Dienste
Kontrolle

Sessions und Berechtigungen

Entzogener Zugriff gilt sofort, nicht erst nach Ablauf des Tokens.

  • Sessions liegen auf dem Server und lassen sich jederzeit invalidieren
  • Die Gültigkeit wird bei jeder Anfrage geprüft, nicht nur beim Login
  • Rollenbasierte Berechtigungen auf Ebene einzelner Pfade
  • Administrationsoberfläche für Anwendungen, Pfade und Benutzer

So funktioniert es

Der Token gelangt niemals in den Browser

Das Frontend kommuniziert ausschließlich mit dem BFF und weist sich mit einem signierten HttpOnly cookie aus. Das BFF prüft bei jeder Anfrage, ob die Session noch gültig ist, und stellt erst dann einen kurzlebigen Token für die Ziel-API aus. Gelingt es einem Angreifer, fremdes Skript in Ihrer Anwendung auszuführen, gibt es nichts zu stehlen — und entzogener Zugriff gilt sofort, nicht erst wenn der Token abläuft.

Das BFF ist dabei ein transparenter Proxy — es leitet Anfragen so weiter, wie das Frontend sie geschickt hat. Bei Entwicklung und Debugging sehen Sie deshalb die realen API-Aufrufe und müssen bei der Fehlersuche nicht rekonstruieren, was zwischen den Schichten wirklich passiert ist. Die gesamte Lösung ist für Projekte gedacht, in denen ein eigenes BFF als zusätzliche Anwendungsschicht keinen Sinn ergibt — statt dass jedes Projekt es selbst baut und betreibt, ersetzt es ein zentrales.

Browser

HttpOnly cookie

BFF-Proxy

prüft die Session, stellt JWT aus

Geschützte API

Bearer Token

Zweites Projekt

SancMeld

Abgleich mit den Sanktionslisten von EU, UN und OFAC

Eine .NET-Lösung, die mit einer Reihe geplanter Cron-Jobs die verfügbaren Sanktionslisten laufend herunterlädt und darin nach Treffern sucht. Enthalten ist ein auf ML.NET aufgebauter Prädiktionsmechanismus, der einzuschätzen hilft, wie relevant ein gefundener Treffer ist.

.NETML.NETEU · UN · OFAC
  • Cron-Jobs laden und verarbeiten laufend die Listen von EU, UN und OFAC
  • Die Treffersuche läuft immer auf der aktuellen Version der Listen
  • Ein auf ML.NET aufgebauter Prädiktionsmechanismus bewertet die Treffer
  • Eine einzige .NET-Lösung — als Service bei Ihnen oder bei uns betreibbar

Zusammenarbeit

Drei Wege, unsere Lösungen zu betreiben

Der Code ist offen — Sie können alles selbst machen. Wenn Sie möchten, helfen wir: vom Support bis zum vollständig verwalteten Betrieb.

Bezahlter Support

Sie betreiben die Lösung selbst und haben garantierte Hilfe von uns — Beratung, Fehlerbehebung und Unterstützung bei Updates.

Deployment und Betrieb bei Ihnen

Wir stellen die gesamte Lösung auf Ihrem Server oder in Ihrer Cloud bereit und übernehmen den Betrieb — Updates, Monitoring und Sicherheitspatches.

Ein Tenant auf der CPD-Instanz

Sie möchten nichts betreiben? Kaufen Sie einen Tenant auf unserer Instanz und nutzen Sie die Lösung als Service.

Warum offen

Ein Autorisierungsserver ist genau die Art Komponente, die niemand selbst schreiben will und der man zugleich glaubwürdig unter die Haube schauen können muss. Geschlossener Code schafft dieses Vertrauen nicht.

Sie können die Lösung in Eigenregie betreiben und einsetzen — oder einen der Wege oben wählen.

  • Kein Vendor Lock-in

    Gebaut auf den Standards OpenID Connect und OAuth 2.0. Sollten Sie sich eines Tages für einen Wechsel entscheiden, gehen Sie mit einem Standardprotokoll — nicht mit unserer Konvention.

  • Auditierbar

    Den gesamten Autorisierungsfluss können Sie Zeile für Zeile nachvollziehen — auch in Ihren eigenen Sicherheitsaudits.

  • Gebaut auf bewährten Komponenten

    OpenIddict und ASP.NET Identity. Weder Kryptografie noch Protokolle haben wir neu erfunden — wir haben sie zu einem Ganzen verbunden, das sich in einem Zug einsetzen lässt.

  • Noch Proof of concept

    Autorisierungsserver, BFF-Proxy, Anwendungsregistrierung und Administration funktionieren. Für den Produktiveinsatz feilen wir noch an der Lösung — und behaupten nichts anderes.