Las bibliotecas, una pregunta cada una

Programas como authnd y authn-bridge están construidos a partir de módulos que se publican, se versionan y se prueban por separado. Cada uno responde una pregunta, y un programa importa aquellos cuyas preguntas plantea.

Todos son Go puro y se compilan con CGO_ENABLED=0.

Cómo se agrupan

Factores: si una persona está presente. mfa decide cuánta prueba basta y no sabe nada de ningún dispositivo. totp es un factor: un código de un teléfono. fido habla CTAP con una llave de seguridad y no sabe nada de ninguna política; keyfactor es la única pieza que importa ambos, y convierte una llave en un factor.

El directorio, y su protocolo. directory es el modelo: una persona, y qué credenciales guarda un origen para ella —una contraseña, un hash NT, un verificador, claves SSH, un secreto de código de un solo uso—, y, aparte de ellas, los atributos que la describen y no prueban nada. ldap es el protocolo LDAP en la red, como servidor, y el esquema de directorio contra el que se puede comprobar una entrada; lo que responde es asunto del manejador.

Kerberos, en dos mitades. krb5 acepta tickets: una keytab, un AP-REQ que entra, un AP-REP que sale. kdc los emite, a partir de un directorio que guarda contraseñas.

Federación y tokens. saml es un proveedor de servicios SAML 2.0 delante de una federación como RENATER o eduGAIN. oidc verifica los tokens OpenID Connect que firma un proveedor: la mitad del servidor de recursos, sin flujo de inicio de sesión.

Revocación y certificados. krl lee, escribe y comprueba las listas de revocación de claves de OpenSSH. servercert da a un demonio su certificado TLS, a partir de archivos o de ACME.

wireguard transporta la lista firmada de claves públicas WireGuard que las personas han registrado ante un proveedor, y que una pasarela convierte en pares.

Por qué son módulos separados

Un servicio que solo acepta tickets nunca enlaza un KDC. Un servidor NFS verifica los tickets que presenta un cliente; tiene una keytab y nada más que ver con un reino. Si aceptar y emitir fueran un solo módulo, cada uno de esos servidores llevaría una ruta de código de emisión de tickets que nunca ejecuta, y el módulo de directorio del que un KDC lee las personas, que nunca usa.

Esto está medido, no es una intención. En un módulo temporal que solo importa 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 misma orden para un módulo que importa github.com/go-authn/kdc@v0.4.3 lista github.com/go-authn/directory y github.com/go-authn/kdc: emitir necesita las personas, aceptar no.

La misma regla se cumple en los demás. mfa no importa nada fuera de la biblioteca estándar, y fido no importa mfa: un programa que solo quiere hacer parpadear una llave no lleva un paquete de políticas. totp solo depende de mfa, y oidc no tiene ninguna dependencia. directory mantiene sus orígenes LDAP, SQL y HCL en subpaquetes: el paquete principal no importa nada fuera de la biblioteca estándar, y sqldir recibe un *sql.DB, así que el controlador de base de datos lo elige el programa.

Todas las páginas tienen las mismas partes

La pregunta; la línea go get de la versión descrita; un ejemplo mínimo que compila contra esa versión; lo que el módulo rechaza, según su código; y contra qué se comprueba: la implementación que no es esta, nombrada en su CI o en sus pruebas. Donde un README y el código discrepan, la página sigue al código.