Produits Entr'ouvert » Authentic 2

Mécanique qui doit permettre aux SP de pouvoir gérer l'authentification multifacteur en demandant/recevant un niveau d'authentification spécifique via les assertions SAML.

Ce ticket s'appuie sur et est la suite du gros ticket a2 #32007.

Ticket relié à trois autres (j'ajouterai les liens quand ils seront publiés) :
- Envoi des niveaux d'auth des rôles via le provisionning dans hobo (#32381)
- Gestion symmétrique du SAML dans mellon (#32376)
- Exemple concret d'intégration dans Chrono (#32379)

Ces quatre tickets mis ensembles, voilà un exemple de ce qui marche :
- Créer deux agendas et deux roles.
- Mettre role de visualisation de agenda 1 à role 1 (resp 2).
- Mettre role 2 niveau 2.
- Mettre role 1 et role 2 à un utilisateur.
- Sur le /manage/ de chrono, l'utilisateur peut voir les deux agendas.
- L'utilisateur peut cliquer sur agenda 1 et le voir.
- Quand il clique sur agenda 2, il est redirigé vers a2 pour une montée d'auth, puis il peut voir l'agenda.

(n'est pas encore géré le cas superuser (aka rôle administrateur), mais je vois comment faire et c'est pas très compliqué)

À part ça il y a plein de choses à dire sur l'approche de ce ticket, qui n'est pas hyper sexy.

Comportement attendu : actuellement une brique reçoit des rôles via le provisionning hobo, et les associe à des actions autorisées. Lorsqu'un utilisateur veut faire une action, c'est à la brique de vérifier si il a le rôle qui autorise cette action. Pour introduire le multifacteur, on associe un niveau d'authentification requis à un rôle, qui est connu de la brique via ce même provisionning. Donc en plus de la vérification précédente, une brique va devoir vérifier que le niveau d'authentification de l'utilisateur courant lui donne le droit de faire usage d'un rôle, et sinon demander à a2 une montée d'auth.

Contraintes et prérequis à avoir en tête (pas gravés dans le marbre non plus) :
1. La norme SAML ne dit rien sur le concept de niveau d'authentification, et ne prévoit pas vraiment qu'il y en ait.
2. Comme un niveau dit quelque chose sur l'authentification d'un utilisateur, on doit l'envoyer dans l'attribut AuthnContext de l'assertion SAML (et pas dans une extension random). À fortiori on doit utiliser le sous attribut AuthnContextClassRef, dans lequel on a le droit de mettre une et une seule URI qui va contenir le niveau.
3. On utilise déjà, quoique mollement, l'attribut AuthnContextClassRef pour parler de la méthode d'authentification utilisée (genre password ou certificat SSL).

Idée 1 : on envoie à la fois la méthode d'authentification et le rôle associé dans l'assertion. C'est propre. C'est aussi impossible, voir le point 2 ci-dessus et la mention « une et une seule URI ».

Idée 2 : on envoie pas les niveaux, mais toujours la méthode d'authentification. L'avantage c'est qu'on reste bien dans la norme, mais garder en tête le point 3 ci-dessus, à savoir que c'est une information dont on ne se sert pas au final. Ensuite le SP est responsable d'attribuer un niveau à cette méthode, et de faire sa tambouille. Premièrement, il faudrait mettre plein de code côté SP pour ces logiques d'associations, pour un résultat pas forcément plus propre. Mais le principal problème c'est qu'on a envie de faire l'association méthode/niveau d'auth côté a2, pour centraliser la conf. Donc il faudrait rajouter du provisionning, ça devient compliqué.

Idée 3 (l'heureuse élue) : on envoie la méthode d'authentification uniquement quand un utilisateur s'authentifie à proprement parler (ie passe de pas connecté à connecté, ce qui correspond implicitement à un niveau d'auth de 1). Quand il s'agit de transmettre l'info qu'un utilisateur a un niveau d'auth plus élevé, on envoie ce niveau via une URI à nous de la forme https://entrouvert.org/auth-level/{2,3,4,5}. Avantage, on ne modifie pas le comportement de base, et la logique à mettre en place est relativement simple. Inconvénient, on a un comportement un peu inconsistant, où on se sert d'un même attribut SAML pour envoyer deux infos un peu différentes selon le contexte (méthode précise sans niveau, puis niveau sans méthode).

Voilà, on en est au stade PoC, il faudra peut-être passer par une PoC de l'idée 2 si la présente est jugée trop sale. Le mieux resterait qu'un gourou SAML ait une idée 4 qui soit grave mieux que celles présentées ici.