Utilisateurs, groupes et annuaires

Un bloc user est tout l’annuaire d’un foyer. Un site dont les personnes sont déjà dans une base de données ou dans LDAP ne devrait pas les recopier dans un second endroit qui se périme : un bloc users les lit donc là où elles sont.

users "sql" {
  driver   = "postgres"                 # or sqlite, or mysql
  dsn_file = "/etc/fileshare/dsn"       # a DSN holds a password: it lives in a file
  users    = "select login, null, nt_hash, ssh_keys from staff"
  groups   = "select team, member from team_members"
}

users "ldap" {
  url                = "ldaps://ldap.example.org"
  base_dn            = "ou=people,dc=example,dc=org"
  bind_dn            = "cn=reader,dc=example,dc=org"
  bind_password_file = "/etc/fileshare/bind.pw"
}

Les requêtes vous appartiennent, parce que les personnes d’un site ont déjà la forme de ce site ; un schéma inventé ici obligerait à les recopier dans un second. Les colonnes de la requête des personnes sont lues par position, pas par nom : un nom, puis tout ou partie d’un mot de passe, d’une empreinte NT, de clés SSH (une par ligne) et d’un secret TOTP, dans cet ordre. Un NULL est un identifiant que cette personne n’a pas : c’est pourquoi l’exemple sélectionne null pour le mot de passe. Une colonne de mot de passe est prise comme le mot de passe lui-même : il n’y a ici aucun réglage pour un mot de passe haché.

Côté LDAP, c’est ce qu’un annuaire compatible Samba publie déjà qui est lu — sambaNTPassword, sshPublicKey, memberUid. L’emplacement des personnes et des groupes, et les attributs qui les nomment, sont configurables : user_filter (par défaut (objectClass=posixAccount)), user_attribute (uid), group_base_dn (base_dn), group_filter ((objectClass=posixGroup)), group_attribute (cn), group_member_attribute (memberUid), et totp_attribute, qui n’a pas de valeur par défaut. sambaNTPassword et sshPublicKey sont lus sous ces noms.

L’ordre, et la seule exception

Les sources sont interrogées dans l’ordre où elles sont écrites, et la première qui connaît un nom en est propriétaire. Les blocs user et group viennent en premier : un compte de service inscrit localement n’est donc pas supplanté par quelqu’un du même nom dans LDAP.

Les groupes sont l’exception : les membres d’un groupe sont l’union de toutes les sources, parce qu’une équipe peut avoir des personnes dans un fichier et dans une base de données.

share "photos" {
  allow   = ["@engineers", "alice"]
  writers = ["@owners"]
}

Ce qu’une source peut prouver, et ce dont chaque protocole a besoin

C’est la partie qu’un site découvre sinon lors d’un montage : check la dit donc en premier :

Une personne qu’un annuaire nomme sans rien prouver pour elle est légitime — un listage avec les secrets ailleurs — et check le dit en une ligne plutôt que de la laisser le découvrir.

Les personnes que nomme le fournisseur d’identité, pas ce fichier

Une fédération — RENATER par l’intermédiaire de go-authn/bridge, par exemple — sait qui fait partie d’un projet, et un partage peut le lui demander à elle plutôt que recopier la liste. Avec un bloc oidc :

share "photos" {
  image   = "/srv/photos.img"
  allow   = ["oidc:groups:urn:mace:univ-example.fr:photos", "oidc:user:bob@univ-example.fr", "alice"]
  writers = ["oidc:groups:urn:mace:univ-example.fr:photos"]
}

oidc:groups:<value> désigne quelqu’un dont la revendication de groupes du jeton contient la valeur ; oidc:user:<name> désigne quelqu’un que le jeton nomme. La graphie est celle d’opkssh, pour qu’un seul vocabulaire dise qui atteint un shell et qui atteint un partage. Quelqu’un que nomme une règle est connu de ce serveur pour autant que le fournisseur le garantisse — les partages ouverts compris — et quelqu’un qu’aucune règle ne nomme reste un inconnu. Les mêmes règles s’appliquent en SFTP, où les groupes voyagent dans le certificat plutôt que dans le jeton.

Quels établissements

oidc {
  issuer   = "https://login.example.org"
  audience = "fileshare"
  domains  = ["univ-a.fr", "univ-b.fr"]   # nobody else from the federation gets in
}

share "projet-x" {
  image   = "/srv/projet-x.img"
  allow   = ["oidc:groups:urn:mace:univ-a.fr:projet-x", "oidc:domain:univ-b.fr"]
  writers = ["oidc:groups:urn:mace:univ-a.fr:projet-x"]
}

domains est vérifié à l’authentification, en SFTP comme en WebDAV, et pour les certificats clients NFS : un nom doit être de la forme <something>@<one of them>, comparé en entier (evilunivb.fr n’est pas univb.fr). oidc:domain: est le même test pour un seul partage. On peut faire confiance au domaine autant qu’au fournisseur : go-authn/bridge écarte un eppn ou un subject-id dont les métadonnées de fédération de l’IdP ne lui accordent pas la portée (scope).

Les groupes sont ce que l’IdP de l’établissement publie, transformé en revendication groups par le claims { groups = [...] } de go-authn/bridge : eduPersonEntitlement par défaut (les groupes d’un laboratoire ou d’une VO), ou eduPersonScopedAffiliation (staff@univ-a.fr, student@univ-b.fr).