Produits Entr'ouvert » Authentic 2

Alors, si on résume un peu l’affaire :
· il y a eu #79230 où, pour faire les choses dans le respect du consentement de l’usager, on ne fournissait un sub que si l’usager avait consenti à transmettre ses données au service identifié :

        if not auth_manager.filter(user=user, expired__gte=now()).exists():
            return {}
        return {'id': utils.make_sub(self, user)}

J’ai l’impression que, plutôt que de faire du billard à trois bandes (en se disant qu’on va masquer la case à cocher pour stocker toujours cette autorisation et donc avoir le sub à coup sûr), on pourrait, dans la réponse retournée par l’endpoint de #79230, ajouter un champ pour définir s’il existe une autorisation connue ou non.

Et donc à l’appel de /api/users/<uuuid>/service/<slug> on aurait une réponse du genre :

{
  "err":0,
  "result":1,
  "data": {
    "service": {
      "slug":"slug-du-service",
      "name":"Nom du service",
      "type":"LibertyProvider" (SAML) ou "OIDCClient" (OIDC)
    },
    "user": {
      "id": "le sub ou le nameid", # <- possiblement pré-généré, notamment si l’usager n’a pas encore d’autorisation explicite
      "existing_authz": true/false # <- en fonction de si auth_manager.filter(user=user, expired__gte=now()).exists()
    }
  }
}

Cela me paraît un moindre mal plutôt que de désactiver la possibilité pour l’usager de donner une autorisation ponctuelle pour un seul SSO, mais peut-être je loupe un truc ?

maintenant, on souhaiterait pouvoir connaître ce sub quand bien même aucune autorisation existerait en base.

Pas tout à fait : je veux connaître le sub si une autorisation a déjà eu lieu.

Dans ma proposition, pour que ça soit très explicite, j'en fais une configuration, qu'on dise explicitement à Authentic d'enregistrer les autorisations pendant x temps (et pour les fous, genre, 10 ans).

Dans la réalité des usages, ça ne me semble pas être un gros sacrifice à la vie privée (mais je veux bien en débattre). Et ça reste parfaitement optionnel.

(...) ajouter un champ existing_authz pour définir s’il existe une autorisation connue ou non.
Cela me paraît un moindre mal plutôt que de désactiver la possibilité pour l’usager de donner une autorisation ponctuelle pour un seul SSO, mais peut-être je loupe un truc ?

Si on fait ça, alors le filtre user|get_user_by_service:"oidcclient" dans wcs/combo devra toujours renvoyer le sub, que existing_authz soit vrai ou pas (parce que sinon mon cas d'usage tombe à l'eau, où je veux obtenir le sub, je dois l'avoir, y compris des gens qui n'ont pas accepté l'enregistrement de l'autorisation)...

Et donc on va avoir ce sub y compris quand celui-ci aura été expiré (ou parce que l'utilisateur aura demandé une dé-fédération, ou autre), et ça m'ennuie un peu plus, parce qu'on ne pourra jamais couper le lien en flinguant les autorisations (ok, c'est assez illusoire). Mais surtout, ça ne permettra pas de savoir si la personne a déjà donné un jour son autorisation -- et ça c'est assez bloquant pour l'usage recherché.

Voilà pourquoi je pensais à ce patch un peu plus profond dans la gestion des autorisations.

Last but not least : pour les poweruser, si on garde "la possibilité pour l’usager de donner une autorisation ponctuelle pour un seul SSO" mais qu'on lui montre par ailleurs sur Publik qu'on a gardé le lien entre Publik et le service tiers (le sub), alors je trouve ça un peu... crasse.

Note que pour aller dans le sens de ta proposition, je pourrais imaginer un filtre « user|get_user_by_service_toujours_toujours:"oidcclient" » qui se ficherait du existing_authz mais (a) j'ai pas d'idée de nom (b) c'est pas simple à expliquer (c) reste le pépin de l'usager qui n'a encore jamais lancé de SSO vers ce service.

Ok ok je comprends mieux, et en particulier l’usage du filtre qui fait qu’il est plus important, dans ce cas ci, d’avoir un sub valide plutôt que de laisser à l’usager la possibilité de ne pas enregistrer son autorisation.

Je vais relire le patch proposé ici et qui part dans cette direction.

Automatic expiration