Bonjour
Notre instance Simplicité est paramétrée pour se connecter via un idp. Cela crée automatiquement un utilisateur et lui affecte un droit en lecture.
Nous souhaiterions étendre cet comportement aux appels API.
Notre instance expose plusieurs API via APIGEE.
Toutes personnes connues de l’IDP peut requêter les api apigee. Nous souhaiterions que lorsque l’appel arrive sur l’instance, cela créé aussi automatiquement un utilisateur.
Nous comptions surcharger le hook preAuth, est-ce la bonne solution ?
Oui mais je ne me rappelle pas ce qui avait été fait à l’époque… Envoie moi le contenu complet du GrantHooks(ou PlatformHooks en v5) en message privé si besoin.
Je voudrais comprendre pourquoi la logique mise en place pour la UI ne s’applique pas aux appels API
Il n’y a rien concernant la création de User dans notre GrantHook (par contre on y a implémenté le preLoadResponsiblity pour ajouter à la volée des responsabilités au User fraichement créé par le login/UI).
OK c’est donc sans doute le sync: true dans la config de l’authentification qui créé l’utilisateur à la volée. Tu confirmes qu’il y a bien ce paramètre ?
Une question => est-il impératif de créer cet utilisateur sur appel API ou est-ce qu’une “substitution” du user (après authent) pour un user technique dédié API ne ferait pas l’affaire ?
Je pose la question vis à vis de la charge induite par une multiplication des grants/objets APIs. De mémoire vous ne faites que de la consultation via API, donc connaitre le “vrai” utilisateur n’est pas forcément nécessaire puisque les appels en consultation ne laissent pas de traces et qu’il n’y a à priori pas de filtrages liés à l’utilisateur
En effet, dans la plupart des cas il ne sera pas nécessaire de tracer nominativement l’accès dans le cas des GET (accès simples en lecture seule) -> la solution consistant à substituer l’appelant par un user technique dédié est très intéressante.
Néanmoins, d’autres usecases nécessiteront des habilitations spécifiquement octroyées à certains user identifiés -> dans ce cas, soit leur profil est déjà initialisé soit on le crée (ce contexte précis d’appel devra être spécifié avec l’appelant dans le cadre d’un processus défini).
Il suffirait ensuite de procéder à cette substitution si et seulement si l’appelant n’a pas de compte…