Die Bibliotheken, je eine Frage

Programme wie authnd und authn-bridge sind aus Modulen gebaut, die eigenständig veröffentlicht, versioniert und getestet werden. Jedes beantwortet eine Frage, und ein Programm importiert diejenigen, deren Fragen es stellt.

Alle sind reines Go und bauen mit CGO_ENABLED=0.

Wie sie sich gruppieren

Faktoren – ob eine Person anwesend ist. mfa entscheidet, wie viel Nachweis genug ist, und kennt kein Gerät. totp ist ein Faktor: ein Code von einem Telefon. fido spricht CTAP mit einem Sicherheitsschlüssel und kennt keine Richtlinie; keyfactor ist das eine Stück, das beide importiert und aus einem Schlüssel einen Faktor macht.

Das Verzeichnis und sein Protokoll. directory ist das Modell: eine Person und welche Anmeldedaten eine Quelle für sie hält – ein Passwort, ein NT-Hash, ein Verifier, SSH-Schlüssel, ein Geheimnis für Einmalcodes – und, getrennt davon, die Attribute, die sie beschreiben und nichts beweisen. ldap ist das LDAP-Leitungsprotokoll, als Server, und das Verzeichnisschema, gegen das ein Eintrag geprüft werden kann; was es antwortet, ist Sache des Handlers.

Kerberos, in zwei Hälften. krb5 nimmt Tickets an: eine Keytab, ein AP-REQ herein, ein AP-REP hinaus. kdc stellt sie aus, aus einem Verzeichnis, das Passwörter hält.

Föderation und Tokens. saml ist ein SAML-2.0-Service-Provider vor einer Föderation wie RENATER oder eduGAIN. oidc prüft die OpenID-Connect-Tokens, die ein Anbieter signiert – die Hälfte des Resource-Servers, ohne Anmeldeablauf.

Widerruf und Zertifikate. krl liest, schreibt und prüft OpenSSH-Sperrlisten für Schlüssel. servercert gibt einem Daemon sein TLS-Zertifikat, aus Dateien oder über ACME.

wireguard überträgt die signierte Liste der öffentlichen WireGuard-Schlüssel, die Personen bei einem Anbieter registriert haben und die ein Gateway in Peers umwandelt.

Warum sie getrennte Module sind

Ein Dienst, der nur Tickets annimmt, bindet nie einen KDC ein. Ein NFS-Server prüft die Tickets, die ein Client vorlegt; er hat eine Keytab und sonst nichts mit einem Realm zu tun. Wären Annehmen und Ausstellen ein Modul, trüge jeder solche Server einen Codepfad zum Ausstellen von Tickets mit sich, den er nie ausführt, und das Verzeichnismodul, aus dem ein KDC Personen liest und das er nie benutzt.

Das ist gemessen, nicht beabsichtigt. In einem Wegwerfmodul, das nur github.com/go-authn/krb5@v0.3.1 importiert:

$ GOWORK=off go list -deps . | grep go-authn
github.com/go-authn/krb5
$ GOWORK=off go list -m all | grep go-authn
github.com/go-authn/krb5 v0.3.1

Derselbe Befehl für ein Modul, das github.com/go-authn/kdc@v0.4.3 importiert, listet github.com/go-authn/directory und github.com/go-authn/kdc auf: Das Ausstellen braucht die Personen, das Annehmen nicht.

Dieselbe Regel gilt auch anderswo. mfa importiert nichts außerhalb der Standardbibliothek, und fido importiert mfa nicht: Ein Programm, das nur einen Schlüssel blinken lassen will, trägt kein Richtlinienpaket mit sich. totp hängt nur von mfa ab, und oidc hat überhaupt keine Abhängigkeit. directory hält seine LDAP-, SQL- und HCL-Quellen in Unterpaketen: Das Kernpaket importiert nichts außerhalb der Standardbibliothek, und sqldir nimmt eine *sql.DB, sodass der Datenbanktreiber die Wahl des Programms ist.

Jede Seite hat dieselben Teile

Die Frage; die go get-Zeile für die beschriebene Version; ein minimales Beispiel, das gegen diese Version kompiliert; was das Modul ablehnt, aus seinem Code; und wogegen es geprüft wird – die Implementierung, die nicht diese ist, benannt in seiner CI oder seinen Tests. Wo eine README und der Code sich widersprechen, folgt die Seite dem Code.