Les bibliothèques, une question chacune

Des programmes comme authnd et authn-bridge sont construits à partir de modules publiés, versionnés et testés chacun de leur côté. Chacun répond à une question, et un programme importe ceux dont il pose les questions.

Tous sont en pur Go et se compilent avec CGO_ENABLED=0.

Comment ils se regroupent

Les facteurs — si une personne est présente. mfa décide combien de preuves suffisent et ne connaît aucun périphérique. totp est un facteur : un code venu d’un téléphone. fido parle CTAP à une clé de sécurité et ne connaît aucune politique ; keyfactor est la seule pièce qui importe les deux, et fait d’une clé un facteur.

L’annuaire, et son protocole. directory est le modèle : une personne, et les identifiants qu’une source détient pour elle — un mot de passe, une empreinte NT, un vérificateur, des clés SSH, un secret de code à usage unique — et, à part d’eux, les attributs qui la décrivent sans rien prouver. ldap est le protocole réseau LDAP, côté serveur, et le schéma d’annuaire contre lequel une entrée peut être vérifiée ; ce qu’il répond est l’affaire du gestionnaire.

Kerberos, en deux moitiés. krb5 accepte les tickets : un keytab, un AP-REQ en entrée, un AP-REP en sortie. kdc les délivre, à partir d’un annuaire qui détient des mots de passe.

Fédération et jetons. saml est un fournisseur de service SAML 2.0 devant une fédération comme RENATER ou eduGAIN. oidc vérifie les jetons OpenID Connect qu’un fournisseur signe — la moitié serveur de ressources, sans parcours de connexion.

Révocation et certificats. krl lit, écrit et vérifie les listes de révocation de clés OpenSSH. servercert donne à un démon son certificat TLS, à partir de fichiers ou d’ACME.

wireguard transporte la liste signée des clés publiques WireGuard que des personnes ont enregistrées auprès d’un fournisseur, et qu’une passerelle transforme en pairs.

Pourquoi ce sont des modules distincts

Un service qui ne fait qu’accepter des tickets ne lie jamais de KDC. Un serveur NFS vérifie les tickets qu’un client présente ; il a un keytab et rien d’autre à faire avec un royaume. Si accepter et délivrer formaient un seul module, chacun de ces serveurs emporterait un chemin de code de délivrance de tickets qu’il n’exécute jamais, et le module d’annuaire dans lequel un KDC lit les personnes, dont il ne se sert jamais.

C’est mesuré, pas voulu. Dans un module jetable qui n’importe que github.com/go-authn/krb5@v0.3.1 :

$ 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

La même commande, pour un module qui importe github.com/go-authn/kdc@v0.4.3, liste github.com/go-authn/directory et github.com/go-authn/kdc : délivrer a besoin des personnes, accepter non.

La même règle vaut ailleurs. mfa n’importe rien hors de la bibliothèque standard, et fido n’importe pas mfa : un programme qui veut seulement faire clignoter une clé n’emporte pas de paquet de politique. totp ne dépend que de mfa, et oidc n’a aucune dépendance. directory garde ses sources LDAP, SQL et HCL dans des sous-paquets : le paquet principal n’importe rien hors de la bibliothèque standard, et sqldir prend un *sql.DB, si bien que le pilote de base de données est le choix du programme.

Chaque page a les mêmes parties

La question ; la ligne go get de la version décrite ; un exemple minimal qui compile avec cette version ; ce que le module refuse, d’après son code ; et ce contre quoi il est vérifié — l’implémentation qui n’est pas celle-ci, nommée dans sa CI ou ses tests. Là où un README et le code divergent, la page suit le code.